Spherical forums

Sphere Development => Editor Development => Topic started by: Radnen on April 03, 2013, 01:57:43 am

Title: The Sphere Studio v1.2.1
Post by: Radnen on April 03, 2013, 01:57:43 am
Sphere Studio
Welcome to my Ultimate Sphere Editor for Microsoft .NET 4.5 Platforms!

Features:


Links
Website: http://radnen.tengudev.com/editor.html
Download: https://github.com/Radnen/spherestudio/releases/tag/1.2.1
Github: https://github.com/Radnen/spherestudio
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Radnen on April 03, 2013, 02:01:02 am
New Feature:
You can now choose multiple filepaths for your sphere games directories.
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Radnen on April 03, 2013, 06:43:44 pm
Updated:
Now added priorities to your task list. This new list is incompatible with the old list since the binary files differ. That sadly means you can't use the new system with an old task list. However, I believe no one actively used that feature anyways, just like no one actively uses this editor.

You can sort by name or by priority by clicking on the appropriate column headers.
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: DaVince on April 04, 2013, 03:59:01 am
Nice stuff, dude! Give the task list some colors though (red/yellow/green for priorities and grey or duller versions of the red/yellow/green for completed tasks?)

Also, some time has passed. Wondering if anything's changed on the library side  to get it to work natively on Mono?
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Metallix on April 04, 2013, 05:57:01 am
Hmm, I wonder if it would be possible to scan the project scripts for "// TODO" comments and add those comments as tasks.

And is it possible to change the tab size somewhere?  I would like to set it to 4 spaces. ( Also a "use spaces instead of tabs" is very common. But since the old sphere editor does not support that, it would maybe lead to chaos in scripts edited by both editors )
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: alpha123 on April 04, 2013, 12:22:37 pm

Now added priorities to your task list. This new list is incompatible with the old list since the binary files differ. That sadly means you can't use the new system with an old task list. However, I believe no one actively used that feature anyways, just like no one actively uses this editor.

Er... I both actively use the editor and the task list....
I'll probably just copy my tasks from an older version of your editor to the new one.

I don't use the editor for writing code (Emacs FTW), but I do use it for maps, sprites (importing from Photoshop), tilesets, and fonts (importing). It's a very useful tool, thanks for it.
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Radnen on April 04, 2013, 12:38:35 pm

Er... I both actively use the editor and the task list....
I'll probably just copy my tasks from an older version of your editor to the new one.


Oh! Okay then, It's not too big of a problem. I'll just add a version to it, if it's versionless then it's an older one and it'll convert it to the newer format.

Since you said you use it for maps, I've got a surprise for you with my next update. It's a long time overdue and once had this feature before my map editor was rewritten. ;)


Hmm, I wonder if it would be possible to scan the project scripts for "// TODO" comments and add those comments as tasks.


Hmm, that could be tricky, I know visual studio does this, but it's got a very nice parser for that. I'll see what I can do. Most likely I won't scan for it, instead it'll add them as those comments are being made.


And is it possible to change the tab size somewhere?  I would like to set it to 4 spaces. ( Also a "use spaces instead of tabs" is very common. But since the old sphere editor does not support that, it would maybe lead to chaos in scripts edited by both editors )


I'll look into the spaces vs tabs thing.


Nice stuff, dude! Give the task list some colors though (red/yellow/green for priorities and grey or duller versions of the red/yellow/green for completed tasks?)


Hmm, that won't be too hard to do.


Also, some time has passed. Wondering if anything's changed on the library side  to get it to work natively on Mono?


Mono? This uses .NET forms, did you mean "ran in Wine"?
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Flying Jester on April 04, 2013, 12:57:54 pm
+1 for Mono or Wine, or however it would work.

Also, out of curiosity, how would one go about editing what functions exist in the autocomplete? Would it be possible to have multiple configurations for this, like one for Sphere and one for TurboSphere? Or just ones for different versions of Sphere?
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Radnen on April 04, 2013, 01:14:52 pm

Also, out of curiosity, how would one go about editing what functions exist in the autocomplete? Would it be possible to have multiple configurations for this, like one for Sphere and one for TurboSphere? Or just ones for different versions of Sphere?


Easy to modify. Just add/remove lines from docs/functions.txt, but I can try to support the switching of function lists.
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: alpha123 on April 04, 2013, 01:58:05 pm

Oh! Okay then, It's not too big of a problem. I'll just add a version to it, if it's versionless then it's an older one and it'll convert it to the newer format.

That would be convenient, thanks. You don't have to bother though, I can just open the old version and new version side-by-side and copy/paste.

Quote

Since you said you use it for maps, I've got a surprise for you with my next update. It's a long time overdue and once had this feature before my map editor was rewritten. ;)

Cool. :) I much prefer your map editor to the old one. It's a LOT nicer. Some feature for sometime in the future: allow some way (editor plugins?) to customize the entity creator (and ideally other stuff too). For example, I'd like to be able to set the type of monster to use with my Arq framework, then the plugin could generate the code necessary to do that. Perhaps this could be even more extensible; I could set map weather within the editor or something and it would write a little bit of code in the correct file.

Quote


Nice stuff, dude! Give the task list some colors though (red/yellow/green for priorities and grey or duller versions of the red/yellow/green for completed tasks?)

Hmm, that won't be too hard to do.

If possible, it would also be nice if the user could set the colors individually for different tasks. I know the task list is a pretty small feature but personally I find it quite useful.
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: DaVince on April 04, 2013, 05:36:29 pm
Quote
Mono? This uses .NET forms, did you mean "ran in Wine"?

Well, and here I went out of my way to be explicit and say "run natively". :P I guess .NET forms are one of those things that can never be supported in Mono, or something?
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Radnen on April 04, 2013, 06:30:39 pm

Quote
Mono? This uses .NET forms, did you mean "ran in Wine"?

Well, and here I went out of my way to be explicit and say "run natively". :P I guess .NET forms are one of those things that can never be supported in Mono, or something?


Well someone would have to go out of their way to re-implement .NET forms for cross-browser support. There was a library like that out there but I'm not so sure if it's active anymore. Unless Mono has one... And they do! So maybe I can get lucky.

Edit: And I'm lucky, they've got full re-implementation of WinForms 2.0. Back when I started this editor I made it only .NET 2.0, so good call on my end, it is possible perhaps to get this running under Mono and the Mono.Winforms GUI toolkit.


Cool. :) I much prefer your map editor to the old one. It's a LOT nicer. Some feature for sometime in the future: allow some way (editor plugins?) to customize the entity creator (and ideally other stuff too). For example, I'd like to be able to set the type of monster to use with my Arq framework, then the plugin could generate the code necessary to do that. Perhaps this could be even more extensible; I could set map weather within the editor or something and it would write a little bit of code in the correct file.


Well, some of that would take Tung's persist as the back-bone. I could add a plugin interface to the editor, perhaps that would help make it easier to do more custom things such as this.

Update
Edit: I don't want to store extra colors with the task list, but if it helps, I've color coded just the priority. Furthermore, I added a type category, the type category can be set to UI, Bug, Feature, Addition, Gameplay, Art, and Other. Then you can sort by what type of task you feel like finishing, or by name, or by priority. Hitting a column the first time will make it sort ascending, hitting it again will make it flip between ascending and descending, a behavior that's not .NET stock. ;)

Edit2: Optionally there is another layout style I can try out, see the second attachment for the style. Tell me which is better.
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: alpha123 on April 05, 2013, 04:22:17 pm

Well, some of that would take Tung's persist as the back-bone. I could add a plugin interface to the editor, perhaps that would help make it easier to do more custom things such as this.

The idea is that the extension would be able to decide the backbone.
I think if you just add some way for plugins to modify the editor UI, or even replace parts of it like the entity creator, it would open huge areas of possibility for custom Sphere RPG frameworks.

Quote

Edit2: Optionally there is another layout style I can try out, see the second attachment for the style. Tell me which is better.

Hm, I think I like the second one a little better. You can still sort it by type, right?
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Radnen on April 05, 2013, 04:33:00 pm

Hm, I think I like the second one a little better. You can still sort it by type, right?


The second one can't easily be sorted by type (well, it's already sorted anyways). I'm trying to build a way to switch between both views, but the .NET ListBox is causing me nothing but trouble. I'm running into a problem that if you keep it compact and save it, and then reload it, it won't populate the grouped list. And adding new entries to the compact list won't add to the grouped list (but I think I have that fixed now).

The way Microsoft implemented the listbox, if ShowGroup is true, then you can add items to a group, but if it is off you can't. That is not a use case for it, however. The ShowGroup option only affects the display, therefore I should still be allowed to add items to groups even if they aren't being shown. So I've been trying to work around such oddities.

I like both styles, the compact would be great for long task lists (to find a task) while the grouped is good for more organized editing or smaller lists.

Update
I moved to ObjectListView (http://objectlistview.sourceforge.net/cs/index.html) library for the task lists. You want tasks!? Well now I've built a fairly grandiose task manager. I'll post screens later, I'm still configuring the graphical end (colors and what-not). Ok... I think I put too much time into this feature, but there was a lot of good merit to figuring this out. In fact I feel like redoing some other lists to use the ObjectListView Library, because it also adds an awesome tree view (which is nice since the project list is also a tree view!!)

Edit:
Damn it. ObjectListBox is not Mono compatible. And I was doing so well with it!
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: Radnen on April 06, 2013, 09:01:14 pm
New Feature
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.

Furthermore, I'm going to release v1.1.0.0 which will incorporate all of these changes that I have made.

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.
Title: Re: Radnen's Sphere Studio v1.0.1.1
Post by: alpha123 on April 06, 2013, 11:34:12 pm

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!

Quote

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.
Title: Re: Radnen's Sphere Studio v1.1.0.0
Post by: Radnen on April 07, 2013, 03:13:18 am
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.
Title: Re: Radnen's Sphere Studio v1.1.0.0
Post by: Flying Jester on April 07, 2013, 06:49:27 pm
What kind of architecture are you using for your plugins? And what kind of linkage do the plugin DLLs need to have?
Title: Re: Radnen's Sphere Studio v1.1.0.0
Post by: alpha123 on April 07, 2013, 08:40:48 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.0.0
Post by: Flying Jester on April 07, 2013, 08:56:03 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.0.0
Post by: Radnen on April 07, 2013, 09:01:45 pm

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 (https://github.com/Radnen/spherestudio/blob/master/TaskPlugin/TaskPlugin.cs).

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.
Title: Re: Radnen's Sphere Studio v1.1.0.0
Post by: Flying Jester on April 07, 2013, 09:29:46 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.0.0
Post by: Radnen on April 07, 2013, 09:36:59 pm
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).
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: Flying Jester on April 07, 2013, 11:27:17 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: N E O on April 08, 2013, 04:23:45 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: Radnen on April 08, 2013, 06:42:35 pm

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?
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: Fat Cerberus on April 08, 2013, 07:34:58 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: alpha123 on April 08, 2013, 07:39:33 pm
@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. :D
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. :P Although that would be amazingly cool....)
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: Radnen on April 08, 2013, 07:52:32 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: N E O on April 08, 2013, 10:02:14 pm


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.
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: Radnen on April 09, 2013, 01:07:20 am

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.


You are right about vendor lock-in, my editor as good as it is, is currently only for Windows with limited to no Wine support. But that may change in time. One of my stretch goals is to move it over to Mono. However, with reflection, I could in theory create a plugin of any C/C++/Assembly code file, provided I implement a wrapper ('bindings' as it is commonly called).

Now, the Task List for example is not Mono friendly so long as it uses ObjectListView. But if I move it over as a plugin, then it won't break compatibility with the entire editor, Linux and OSX users would simply not download it and instead download an alternative plugin that does work. See, in this regard a plugin system increases the cross-compatibility of my editor since I just need to support the core editor, and not all extra attachments to it.

Edit:
Update
I have gotten rid of the task list. And replaced it with...

... A plugin version of it 100% interfaced with the editor!!! It will update when a project opens, clear when a project closes, etc. I'm still not too happy with the way I introduce it as a dockable container, but I think it's a start. For example there is a close button, which will destroy the control, but what if the plugin creator did not intend for that? So, I think I need to bubble-up the dock-panel to the plugin level, and the plugin writer can style their own panel. Then I'll add some kind of way of having them tell it where to put their dock panel.

Edit:
Now a plugin looks a lot like this when you implement it: TaskPlugin.cs (https://github.com/Radnen/spherestudio/blob/master/TaskPlugin/TaskPlugin.cs).
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: DaVince on April 09, 2013, 10:40:20 am
Oh man, I'm in Windows for a change! Gonna be testing out the editor now.

Edit: oh. Well. I couldn't configure the games path (after selecting something the edit box was still empty), and after closing the settings dialog it just crashes. With subsequent starts, it crashes every time I open the settings dialog. And Microsoft is being wholly unhelpful by showing the stack trace in Dutch.

By the way, how are task lists stored? As an extra file in the Sphere project or something?
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: Radnen on April 09, 2013, 12:23:19 pm

Oh man, I'm in Windows for a change! Gonna be testing out the editor now.

Edit: oh. Well. I couldn't configure the games path (after selecting something the edit box was still empty), and after closing the settings dialog it just crashes. With subsequent starts, it crashes every time I open the settings dialog. And Microsoft is being wholly unhelpful by showing the stack trace in Dutch.


What windows version are you using?


By the way, how are task lists stored? As an extra file in the Sphere project or something?


It's stored in each games root directory. There would be a tasks.list file generated.
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: DaVince on April 09, 2013, 01:38:54 pm
Running Windows 7 Home Premium, 64-bit with service pack 1.

Quote
It's stored in each games root directory. There would be a tasks.list file generated.

That's a good way to do it. :)

Okay, I'm going to just paste the error messages I get and refer you to http://finderr.net/ to help you figure out what kinds of errors they are. Is that fine?
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: DaVince on April 09, 2013, 02:13:17 pm
This is on version 1.0.1.1.

1. On first run, when trying to enable the only plugin:
Code: [Select]
Zie het einde van dit bericht voor meer informatie over het aanroepen 
van JIT-foutopsporing (Just In Time) in plaats van dit dialoogvenster.

************** Tekst van uitzondering **************
System.NullReferenceException: De objectverwijzing is niet op een exemplaar van een object ingesteld.
   bij Sphere_Editor.EditorForm.DockControl(Control ctrl, String name, DockAreas areas, DockAlignment align)
   bij TaskPlugin.TaskPlugin.Initialize()
   bij Sphere_Editor.Utility.PluginWrapper.Activate()
   bij Sphere_Editor.Settings.EditorSettings.PluginList_ItemChecked(Object sender, ItemCheckedEventArgs e)
   bij System.Windows.Forms.ListView.OnItemChecked(ItemCheckedEventArgs e)
   bij System.Windows.Forms.ListView.WmReflectNotify(Message& m)
   bij System.Windows.Forms.ListView.WndProc(Message& m)
   bij System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bij System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bij System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Geladen assembly's **************
mscorlib
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
Sphere Editor
    Assembly-versie: 1.1.1.0
    Win32-versie: 1.1.1.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Sphere%20Editor.exe
----------------------------------------
System.Windows.Forms
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5460 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5462 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Sphere.Plugins
    Assembly-versie: 1.0.0.0
    Win32-versie: 1.0.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Sphere.Plugins.DLL
----------------------------------------
WeifenLuo.WinFormsUI.Docking
    Assembly-versie: 2.7.0.0
    Win32-versie: 2.7.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
System.Windows.Forms.resources
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5420 (Win7SP1.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_nl_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------
ObjectListView
    Assembly-versie: 2.5.1.42131
    Win32-versie: 2.5.1.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/ObjectListView.DLL
----------------------------------------
TaskPlugin
    Assembly-versie: 1.0.0.0
    Win32-versie: 1.0.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Plugins/TaskPlugin.dll
----------------------------------------
mscorlib.resources
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------

************** JIT-foutopsporing **************
Als u JIT-foutopsporing wilt inschakelen, moet in het configuratiebestand voor deze
toepassing of computer (machine.config) de waarde
jitDebugging in het gedeelte system.windows.forms zijn ingesteld.
De toepassing moet ook zijn gecompileerd terwijl foutopsporing
was ingeschakeld.

Bijvoorbeeld:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

Wanneer JIT-foutopsporing is ingeschakeld, worden onverwerkte uitzonderingen
naar het JIT-foutopsporingsprogramma gestuurd dat op de computer is geregistreerd
en worden niet door dit dialoogvenster verwerkt.



2. When clicking OK in the initial configure screen without having (been able to) set the games directory:
Code: [Select]
Zie het einde van dit bericht voor meer informatie over het aanroepen 
van JIT-foutopsporing (Just In Time) in plaats van dit dialoogvenster.

************** Tekst van uitzondering **************
System.ArgumentOutOfRangeException: StartIndex kan niet minder dan nul zijn.
Parameternaam: startIndex
   bij System.Text.StringBuilder.Remove(Int32 startIndex, Int32 length)
   bij Sphere_Editor.Settings.SphereSettings.SetGamePaths(String[] list)
   bij Sphere_Editor.Settings.SphereSettings.SetSettings(EditorSettings SettingForm)
   bij Sphere_Editor.Global.EditSettings()
   bij Sphere_Editor.EditorForm.OpenEditorSettings(Object sender, EventArgs e)
   bij Sphere_Editor.EditorForm.EditorForm_Shown(Object sender, EventArgs e)
   bij System.Windows.Forms.Form.OnShown(EventArgs e)
   bij System.Windows.Forms.Form.CallShownEvent()
   bij System.Windows.Forms.Control.InvokeMarshaledCallbackDo(ThreadMethodEntry tme)
   bij System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj)
   bij System.Threading.ExecutionContext.runTryCode(Object userData)
   bij System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   bij System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   bij System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   bij System.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry tme)
   bij System.Windows.Forms.Control.InvokeMarshaledCallbacks()


************** Geladen assembly's **************
mscorlib
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
Sphere Editor
    Assembly-versie: 1.1.1.0
    Win32-versie: 1.1.1.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Sphere%20Editor.exe
----------------------------------------
System.Windows.Forms
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5460 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5462 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Sphere.Plugins
    Assembly-versie: 1.0.0.0
    Win32-versie: 1.0.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Sphere.Plugins.DLL
----------------------------------------
WeifenLuo.WinFormsUI.Docking
    Assembly-versie: 2.7.0.0
    Win32-versie: 2.7.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
System.Windows.Forms.resources
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5420 (Win7SP1.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_nl_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------
ObjectListView
    Assembly-versie: 2.5.1.42131
    Win32-versie: 2.5.1.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/ObjectListView.DLL
----------------------------------------
TaskPlugin
    Assembly-versie: 1.0.0.0
    Win32-versie: 1.0.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Plugins/TaskPlugin.dll
----------------------------------------
mscorlib.resources
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
System.Xml
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5420 (Win7SP1.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

************** JIT-foutopsporing **************
Als u JIT-foutopsporing wilt inschakelen, moet in het configuratiebestand voor deze
toepassing of computer (machine.config) de waarde
jitDebugging in het gedeelte system.windows.forms zijn ingesteld.
De toepassing moet ook zijn gecompileerd terwijl foutopsporing
was ingeschakeld.

Bijvoorbeeld:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

Wanneer JIT-foutopsporing is ingeschakeld, worden onverwerkte uitzonderingen
naar het JIT-foutopsporingsprogramma gestuurd dat op de computer is geregistreerd
en worden niet door dit dialoogvenster verwerkt.


3. When clicking Project > Configure Sphere
Code: [Select]
Zie het einde van dit bericht voor meer informatie over het aanroepen 
van JIT-foutopsporing (Just In Time) in plaats van dit dialoogvenster.

************** Tekst van uitzondering **************
System.ArgumentException: Het pad heeft een ongeldige indeling.
   bij System.IO.Path.NormalizePathFast(String path, Boolean fullCheck)
   bij System.IO.Path.NormalizePath(String path, Boolean fullCheck)
   bij System.IO.Path.GetDirectoryName(String path)
   bij Sphere_Editor.EditorForm.OptionsToolButton_Click(Object sender, EventArgs e)
   bij System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   bij System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   bij System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   bij System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   bij System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   bij System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   bij System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   bij System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   bij System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   bij System.Windows.Forms.Control.WndProc(Message& m)
   bij System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   bij System.Windows.Forms.ToolStrip.WndProc(Message& m)
   bij System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   bij System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bij System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bij System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Geladen assembly's **************
mscorlib
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
Sphere Editor
    Assembly-versie: 1.1.1.0
    Win32-versie: 1.1.1.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Sphere%20Editor.exe
----------------------------------------
System.Windows.Forms
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5460 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5462 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Sphere.Plugins
    Assembly-versie: 1.0.0.0
    Win32-versie: 1.0.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Sphere.Plugins.DLL
----------------------------------------
WeifenLuo.WinFormsUI.Docking
    Assembly-versie: 2.7.0.0
    Win32-versie: 2.7.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
System.Windows.Forms.resources
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5420 (Win7SP1.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_nl_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------
ObjectListView
    Assembly-versie: 2.5.1.42131
    Win32-versie: 2.5.1.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/ObjectListView.DLL
----------------------------------------
TaskPlugin
    Assembly-versie: 1.0.0.0
    Win32-versie: 1.0.0.0
    CodeBase: file:///D:/games/sphere/editors/SphereStudio-1.0.1.1/Plugins/TaskPlugin.dll
----------------------------------------
mscorlib.resources
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
System.Xml
    Assembly-versie: 2.0.0.0
    Win32-versie: 2.0.50727.5420 (Win7SP1.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

************** JIT-foutopsporing **************
Als u JIT-foutopsporing wilt inschakelen, moet in het configuratiebestand voor deze
toepassing of computer (machine.config) de waarde
jitDebugging in het gedeelte system.windows.forms zijn ingesteld.
De toepassing moet ook zijn gecompileerd terwijl foutopsporing
was ingeschakeld.

Bijvoorbeeld:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

Wanneer JIT-foutopsporing is ingeschakeld, worden onverwerkte uitzonderingen
naar het JIT-foutopsporingsprogramma gestuurd dat op de computer is geregistreerd
en worden niet door dit dialoogvenster verwerkt.


There are many more crashes; no matter what option I select, it'll show some related error message. I think one of the issues might be because it doesn't have a Sphere engine or games folder to refer to. You should detect whether the given path exists/isn't empty and try to display the config dialog when there's issues with it. (Maybe you already do? After all, trying to open the settings makes it crash for me...)
Title: Re: Radnen's Sphere Studio v1.1.1.0
Post by: Radnen on April 09, 2013, 07:30:17 pm
I have recently fixed the second issue you got. The first one might be fixed since re-coding those troublesome methods. The last one is hard to say, that menu option should have been inactive if there was no path, I'll look into the matter. You might have been able to catch it in an undetermined state. See, it's good of you to catch these, I have a certain... process I got used to. :) It's like play testing a game. I'm bad at play-testing my own games because.... I know everything! I know if a chest is not working or a door is inactive.

The editor is only for x86 systems (or above), so it's okay if you run a 64 bit computer (I run 64 bit as well). I may not do an x64 version since the libraries I use do not support x64 out of the box.

Edit:
I have released v1.1.2.0, which has many, many improvements.
- The task editor is now a standalone plugin
- The image editor can now properly resize an image.
- The Map editor doesn't show full tile selection when on a tool other than the Pen tool.
- The image editor is flagged as dirty when editing images.
- The script editor now has font support (now you can change the font). (not yet the spacing... but soon).
- The Sphere Config is now not able to be clicked on if you cancel out of the initial settings dialog.
- The Scripts menu item only shows when a scriptbox is active.
- The Plugin system now let's you style your own dock content and listview items. (still not ready for full-on plugin creation).
- Made the project list view load a thousand times faster now. Yes, a thousand or a million depending on the # of files in your project.
- Fixed error with empty paths in multi-path game box.
- Added description text to folder browser in game paths and sphere folder dialog boxes.
- Fixed View menu from listing empty forms and not reordering the items in the list. - The default .NET code always sucks.
- Added tile removal back into map tileset editor. (Was off for the last few versions).
- Made image editor remember the blend mode when switching between images.
- Updated ObjectListView to latest version.
- Set Cursor to a loading cursor when loading projects, not that it matters anymore.

Still a million more things to do!

Edit2:
Just to let you know, the task list is definitely something you can't 'port over', so remember your old list, and be prepared to rewrite it. After this though, there is no more updates to the format.
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: DaVince on April 11, 2013, 03:37:53 pm
Nice work! But I'm still having issues.

In the editor settings, clicking Browse and selecting a folder still doesn't fill in the Sphere engine path for me. Selecting game paths does work, however. Also, after confirming my settings (after manually entering Sphere's path), I can't open the Configure Sphere window.

Also a small request: tab closing with ctrl+W! I use it all the time rather than ctrl+F4. :P
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: alpha123 on April 11, 2013, 06:12:08 pm

Also a small request: tab closing with ctrl+W! I use it all the time rather than ctrl+F4. :P

Same. Ctrl+F4 is rather inconvenient to hit; Ctrl+W is a lot nicer. Isn't Ctrl+W standard? Firefox seems to accept both Ctrl+W and Ctrl+F4 though.
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Radnen on April 11, 2013, 07:00:22 pm
I will attempt to hack out Ctrl+W; Ctrl+F4 is actually a standard, but seeing as there are multiple standards it's wise for me to try and support both. Also, middle-mouse-wheel clicking removes tabs as well.

@DaVince: You need to have engine.exe and config.exe in the folder you specify. I can't replicate your behavior, because it should just work! I'll wait and see if more people have that issue, because I just can't see it happen unless you don't have engine.exe and config.exe directly in the folder. Also... You were able to write in config.exe, but not open it? I wonder if there are certain privilege rights blocking your access? You are on Windows, did you try turning off the stupid UAC rules?
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Fat Cerberus on April 11, 2013, 08:18:00 pm

You are on Windows, did you try turning off the stupid UAC rules?


People always suggest this, but this is a bad idea. Turning UAC off leaves the account with full admin privileges at all times--the equivalent to logging in as root on Linux.  The problem is that programmers still seem to think it's okay to save config data in Program Files, which is poor practice to begin with.
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Radnen on April 11, 2013, 08:20:12 pm


You are on Windows, did you try turning off the stupid UAC rules?


People always suggest this, but this is a bad idea. Turning UAC off leaves the account with full admin privileges at all times--the equivalent to logging in as root on Linux.  The problem is that programmers still seem to think it's okay to save config data in Program Files, which is poor practice to begin with.


Then what if I told you Linux does it better than Windows? ;)
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Fat Cerberus on April 11, 2013, 08:22:37 pm
How so?  A UAC prompt is the equivalent of Linux asking for the root password.
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Radnen on April 11, 2013, 09:13:42 pm

How so?  A UAC prompt is the equivalent of Linux asking for the root password.


Yes, that's right. But, I have never had the same issues with UAC as I have had with Linux. People weren't able to get Sphere running, by putting it in program files for example. Plus the filesystem in Windows is not "standardized" in the way that Linux's is. In Windows you can't assume the location of the users and documents; case in point win XP has different locations for these than Win 7. Windows programmers long ago have given up trying to store config files in one place. Now there are several ways of doing this and UAC can pop up due to something not being placed in the right place for Win 7, especially for older programs like Sphere.

Plus I've gotten UAC prompts far more numerous times than the equivalent in Linux. Basically, it got annoying.
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Flying Jester on April 11, 2013, 09:30:45 pm
It's because Linux never let programmers assume their programs could just run with root privileges at all times. In fact, a lot programs will give warnings if run as root (some even say things like "Running as root? Very stupid!") Generally, Linux programs have always been written to not need admin privileges unless absolutely necessary.

It's very rare for an ordinary program to ever need root privileges in Linux. Because it's very rare that you ever actually need to do things that require admin or root privileges.
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Radnen on April 12, 2013, 12:58:03 am
I should also add that UAC popups don't ask for a password. I'm still very much a single user, it does not force me into admin 100% of the time. I still have to explicitly run programs 'as admin' in win 7. It's just Microsoft being stupidly overprotective.

Edit:
Update
I have added indentation 2 and 4 spaces, as well as the ability to toggle between tabs and spaces. Tabs aren't converted to spaces when that happens tho, so you'll have to change them manually, which is easy: select all, then indent all by 1, and then unindent. Scintilla will then automatically change to spaces for code that had been using tabs. Or conversely, turn it off the very first time and never worry about it.

Update
Added code folding, current line highlighting, and brace matching. I have finally beat Scintilla into submission, mwahahaha!
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: DaVince on April 12, 2013, 09:01:12 am

I will attempt to hack out Ctrl+W; Ctrl+F4 is actually a standard, but seeing as there are multiple standards it's wise for me to try and support both. Also, middle-mouse-wheel clicking removes tabs as well.

Thanks!

Quote
@DaVince: You need to have engine.exe and config.exe in the folder you specify. I can't replicate your behavior, because it should just work! I'll wait and see if more people have that issue, because I just can't see it happen unless you don't have engine.exe and config.exe directly in the folder.

config.exe and engine.exe are in there. It's a bog standard Sphere 1.5 installation (but it does this for all the other versions I have too).

Quote
Also... You were able to write in config.exe, but not open it? I wonder if there are certain privilege rights blocking your access? You are on Windows, did you try turning off the stupid UAC rules?

Uh... Not sure what you're talking about. config.exe works fine, it's your editor where the option to open config.exe is grayed out in the menu now (probably after your last modification related to this).
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Radnen on April 12, 2013, 01:50:04 pm
DaVince, I think I see it now. You wanted to open the config and engine without a project loaded, right? I have turned these on, the old sphere editor didn't allow you to run either one without a project open. Anyways, I still don't know how you are getting the 'sphere folder' dialog to not fill in the editor and config! I don't know where to begin... But I'll look into it.
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: DaVince on April 12, 2013, 03:41:22 pm

DaVince, I think I see it now. You wanted to open the config and engine without a project loaded, right? I have turned these on, the old sphere editor didn't allow you to run either one without a project open. Anyways, I still don't know how you are getting the 'sphere folder' dialog to not fill in the editor and config! I don't know where to begin... But I'll look into it.

Just to let you know, the game paths list does fill up, so since that seems to work maybe you can use that for the engine directory selector. (Though I find Windows' folder selection dialog rather inconvenient: no path pasting and it keeps scrolling so my current selected directory is always at the bottom of the view pane!)
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Fat Cerberus on April 12, 2013, 04:15:11 pm
That's the old-style folder selection dialog.  Most new apps I've seen use a dialog similar to the file selection box (so you can paste a path), so it's probably just a matter of calling the correct API.
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Radnen on April 12, 2013, 05:29:08 pm

That's the old-style folder selection dialog.  Most new apps I've seen use a dialog similar to the file selection box (so you can paste a path), so it's probably just a matter of calling the correct API.


I can't target an API out of .NET 2.0, this is so I could make it mono compatible when the time comes to move it over and make it cross-platform. Maybe I could use a file dialog box instead?
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Fat Cerberus on April 12, 2013, 07:01:53 pm
I'll check out the .NET docs later tonight when I have access to my own laptop and let you know.

Edit: Bummer.  Looks like the new folder selection dialog requires custom code to use, it's not natively supported in .NET.  According to the article below, internal methods to do it exist, but it requires reflection to make use of:
http://www.lyquidity.com/devblog/?p=136

Probably way too much work just for a simple .NET Sphere editor.  To answer your question, I believe you can use the file selection dialog for this purpose, but you'd have to parse the filename out of the resulting path and the user wouldn't be able to select a folder that didn't have at least one file in it...
Title: Re: Radnen's Sphere Studio v1.1.2.0
Post by: Radnen on April 13, 2013, 03:01:38 am
I could get lucky and see if Mono project has a slightly better UI for folder browsing. You are right tho, the default Folder browser is ugly, and can't quick select favorite locations or paste in paths. See this stackoverflow spot (http://stackoverflow.com/questions/31059/how-do-you-configure-an-openfiledialog-to-select-folders) for a heated discussion on folder browsers!

Update
I have added a 'presets' section to the options menu. This allows you to set up an environment targeted to different Sphere versions, files, plugins, etc. In this way you can distinguish between TS projects and Sphere projects.

I'll put up v1.1.3.0
- Added preset settings option
- Refactored editor settings saving
- Added script folding
- Added script highlighting
- Added Script brace matching
- Added script font editing
- Added script tab changing
- Added script spaces changing
- Fixed paste button not activating
- Fixed some shortcut keys not activating
- Made project list load faster
- Fixed map editor not selecting single tiles
- Fixed tile addition/removal causing selection box to appear
- Fixed not being able to open engine/config on empty project
- Fixed paste not redrawing image editor
- Added Ctrl+W hotkey
Title: Re: Radnen's Sphere Studio v1.1.3.0
Post by: Radnen on April 13, 2013, 07:23:38 pm
Update
Added Mirror drawing mode to the editor. You can now mirror vertically, and horizontally. This is great in the map editor for when you have to edit terrain and don't want to flip tiles all the time or sprites.
Title: Re: Radnen's Sphere Studio v1.1.3.0
Post by: Fat Cerberus on April 14, 2013, 11:07:45 am
That automatic mirroring functionality looks handy!  Your editor is already miles ahead of the stock editor, Radnen, and it keeps getting better. :). Now all it needs is the ability to change the script editor font and tab size and I'll use it exclusively...
Title: Re: Radnen's Sphere Studio v1.1.3.0
Post by: Radnen on April 14, 2013, 02:10:09 pm

Now all it needs is the ability to change the script editor font and tab size and I'll use it exclusively...


That's standard in 1.1.3.0, see the changelog. :)
Title: Re: Radnen's Sphere Studio v1.1.3.0
Post by: Fat Cerberus on April 14, 2013, 03:08:28 pm
I read well...  :-[. Haha, thanks, now I can finally ditch the old-as-hell default editor!
Title: Re: Radnen's Sphere Studio v1.1.3.0
Post by: Fat Cerberus on April 14, 2013, 11:53:34 pm
Hey, I figured out a solution to the folder dialog issue: Just use an OpenFileDialog with the filter set to only show the correct filename--engine.exe or config.exe.  I've seen a couple apps do this when the executable to be located has a known filename (e.g. foobar2000 with encoders).
Title: Re: Radnen's Sphere Studio v1.1.3.0
Post by: DaVince on April 15, 2013, 06:36:20 am
Good idea, but considering how Sphere is built, letting the user define the .exe would be a bit better. Since for some release games engine.exe is renamed.
Title: Re: Radnen's Sphere Studio v1.1.3.0
Post by: Fat Cerberus on April 15, 2013, 07:16:47 am
Then you should be using an OpenFileDialog instead of a FolderBrowserDialog anyway! :)

Also, a bug (or maybe just an annoying "feature" ;) ) I found: Running the project collapses all folders in the project viewer, every single time.  VERY annoying.  I swear there was another bug I found, but I can't remember what it was now... oh that's right, you can't open a file from the project explorer by pressing Enter, it just dings at you instead.

Oh, and maybe add an option to change the font for the project tree?  Again, the default one is too small on my 1920x1080 laptop display.  Speaking of which, thanks for changing the default for the script editor from Courier New to Consolas, the latter is a much nicer font for programming.
Title: Re: Radnen's Sphere Studio v1.1.3.0
Post by: Radnen on April 15, 2013, 12:38:58 pm

Then you should be using an OpenFileDialog instead of a FolderBrowserDialog anyway! :)


Will do.


Also, a bug (or maybe just an annoying "feature" ;) ) I found: Running the project collapses all folders in the project viewer, every single time.  VERY annoying.  I swear there was another bug I found, but I can't remember what it was now... oh that's right, you can't open a file from the project explorer by pressing Enter, it just dings at you instead.

Yeah, it has to do with the background filesystem watcher (so the tree auto-updates when things are added / removed from outside of the editor). The Sphere engine automatically overwrites the game.sgm as soon as it runs, causing the tree to reset. I could do one of two things here, turn the system watcher off while the engine runs or modify the tree so that adding/removing nodes doesn't collapse it.


Oh, and maybe add an option to change the font for the project tree?  Again, the default one is too small on my 1920x1080 laptop display.  Speaking of which, thanks for changing the default for the script editor from Courier New to Consolas, the latter is a much nicer font for programming.

Hmm, I'll try something out.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Radnen on April 15, 2013, 07:13:33 pm
Alright guys, v1.1.4.0 is out, here's some of the changes:

- added mirror modes to the image drawer
- fixed alpha not updating on color switch in image editor
- added bg to color box to see alpha colors
- optimized image switching, no need to redraw bg if same sized images
- changed folder browser for sphere executables to use a file dialog
- added font editor to tree view
- added error handling to the font editors, (it didn't filter for TT fonts)
- fixed not enough margin for folding on larger script files.
- made project tree show up first on project loads
- quick fix for pausing the modification of the tree view when engine runs.
- added an outline when drawing invisible rectangles in the image editor.
- minor fixes and changes

Get while it's hot! Thanks to some of LordEnglish's suggestions I think it's a bit more comfortable to use now.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Fat Cerberus on April 15, 2013, 11:29:23 pm

Alright guys, v1.1.4.0 is out, here's some of the changes:

- added mirror modes to the image drawer
- fixed alpha not updating on color switch in image editor
- added bg to color box to see alpha colors
- optimized image switching, no need to redraw bg if same sized images
- changed folder browser for sphere executables to use a file dialog
- added font editor to tree view
- added error handling to the font editors, (it didn't filter for TT fonts)
- fixed not enough margin for folding on larger script files.
- made project tree show up first on project loads
- quick fix for pausing the modification of the tree view when engine runs.
- added an outline when drawing invisible rectangles in the image editor.
- minor fixes and changes

Get while it's hot! Thanks to some of LordEnglish's suggestions I think it's a bit more comfortable to use now.


Haha, you even fixed a few bugs I noticed but forgot about!  Thanks for the tree view font switcher Radnen, you're a lifesaver! :) Changed it to 10-point Segoe UI, now it's perfect! You should probably consider using Segoe UI as your default project tree font instead of MS Sans Serif, as it's much easier on the eyes.  Oh, and speaking of fonts, the Sphere font generator is basically useless right now because it renders the characters anti-aliased, which makes the resulting font look blurry when displayed at a lower resolution.  Any way of fixing that?

Oh, regarding the folding margins though... you should probably scale those based on the font size; 10 point is fine in the new version, but up that to 12 and the fold arrows overlap the line numbers again.

Edit: I cloned the spherestudio repo and checked out the code, and it appears you might be able to fix the antialiasing issue by adding...
Code: (csharp) [Select]
g.SmoothingMode = SmoothingMode.None;

...before drawing the characters.  I couldn't test it though as when I went to run the editor I immediately got a null reference exception on TreeContent.Activate();.  I don't know if it's because I'm missing files or what (I had to disable the ClickOnce signing just to run it), or just because I compiled it with VS2012 instead of VS2010, but yeah, couldn't get my own build to run.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Radnen on April 16, 2013, 01:13:05 am
Good one on the smoothing mode, thanks! The red/blue stuff though I cannot get rid of. That has to do with the Windows 'clear type' layer, which you could turn off in the 'appearance and personalization' section of the control panel. There was a way, but it involved hacking the OS (turning it off, then back on), and I don't want to set your User OS settings just to get a feature working right.

Oh damn it, good one on the TreeContent.activate(), apparently I was doing it wrong. The correct interface has to load first before I can activate it. I have made the option of turning on and off the dock panels. They are off by default and so for those first building it with fresh files, you can get such a null reference. I'll fix these changes.

Edit:
If you want to update your fork, you can. Hopefully one can build from scratch again.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Fat Cerberus on April 16, 2013, 01:59:54 am
One more bug report, then I need to get some sleep: If two files have the same filename and you have one of them open, Sphere Studio gets confused if you try to open the other and just switches to the existing tab, even when the files are in different folders.

Oh, and you're not supposed to commit the .csproj.user files!  Those are machine-specific I believe, similar to the hidden .suo file but at the individual project level instead of the solution.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Radnen on April 16, 2013, 02:13:04 am

One more bug report, then I need to get some sleep: If two files have the same filename and you have one of them open, Sphere Studio gets confused if you try to open the other and just switches to the existing tab, even when the files are in different folders.


Yeah, I was relying on the filename rather than the path. I really need to check against the full path.


Oh, and you're not supposed to commit the .csproj.user files!  Those are machine-specific I believe, similar to the hidden .suo file but at the individual project level instead of the solution.


It's in the .gitignore file under .user; I'm surprised that file made it through. It said 8 months ago... If it was going through it'd update each time. It was *supposed* to be deleted. Sigh. I don't know what to do about it.

Edit:
I'm surprised, but it got deleted only when I deleted it (by temporarily moving it out of the repo). This is a weird bug in git. I furthermore added a '*.csproj.user* field in the .gitignore (it shouldn't have made a difference, but now it's stricter... I guess).
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Fat Cerberus on April 16, 2013, 02:22:25 am
Sleep is overrated... I figured out how to solve the ClearType issue without changing the OS settings:
Code: (csharp) [Select]
g.TextRenderingHint = System.Drawing.Text.TextRenderingHint.SingleBitPerPixel
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Radnen on April 16, 2013, 02:34:02 am

Sleep is overrated... I figured out how to solve the ClearType issue without changing the OS settings:
Code: (csharp) [Select]
g.TextRenderingHint = System.Drawing.Text.TextRenderingHint.SingleBitPerPixel



Wow! A while ago when I first tried solving the problem I was looking everywhere and many people resorted to P/Invoke calls that muddled with the OS. I'm glad you found this! I think the word 'hint' hinted you off? 'TextRenderingHint' huh, never knew it existed in the options until now and I've gone over them like dozens of times when originally trying to solve the problem. :o
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Fat Cerberus on April 16, 2013, 09:09:08 am
One minor change to make it perfect: Change that from SingleBitPerPixel to SingleBitPerPixelGridFit.  The latter uses hints in the TT file to make the resulting text look much, much better.

Edit: Hm, looks like characters are being cut off due to not enough space at certain point sizes.  I think I'll experiment some more and see if I can fix all the bugs... :)
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: N E O on April 16, 2013, 01:21:38 pm
For the old editor's font-to-RFN, I was mostly fine with changing Windows' rendering settings before conversion. If you're going to force a particular rendering method in the conversion I really think you should allow the user to choose the setting (even through a simple toggle) instead of forcing one (the Adobe Font Folio version of Helvetica Neue, for example, will almost always look better at small sizes when rendered with anti-aliasing instead of turning it off; don't know if Adobe or Linotype updated the hinting since, but at least until Font Folio 11 this is the case).

Keep in mind that allowing certain methods of anti-aliasing may not be supported outside of Windows. This is where something consistent like FreeType would come in handy, and if I ever add font conversion to my phoenix-based app I'll use it myself.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Fat Cerberus on April 16, 2013, 01:55:09 pm

For the old editor's font-to-RFN, I was mostly fine with changing Windows' rendering settings before conversion. If you're going to force a particular rendering method in the conversion I really think you should allow the user to choose the setting (even through a simple toggle) instead of forcing one (the Adobe Font Folio version of Helvetica Neue, for example, will almost always look better at small sizes when rendered with anti-aliasing instead of turning it off; don't know if Adobe or Linotype updated the hinting since, but at least until Font Folio 11 this is the case).

Keep in mind that allowing certain methods of anti-aliasing may not be supported outside of Windows. This is where something consistent like FreeType would come in handy, and if I ever add font conversion to my phoenix-based app I'll use it myself.


Antialiasing is one thing; you never want ClearType used for a TrueType-to-raster conversation, however, as the conversion invariably looks like crap if rendered at a different resolution or on a different background.  ClearType is something that has to be done in realtime for it to work as intended.  And we can't exactly ask every Sphere user to turn it off manually when generating fonts for Sphere!

Also, the method I figured out for doing this is a standard part of the .NET framework (specifically, the System.Drawing namespace), so there's no reason it shouldn't work in, e.g., Mono.  So I wouldn't be too worried about cross-platform issues in this particular case.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Radnen on April 16, 2013, 02:26:37 pm
I merged your pull request. I feel tempted to make you a developer on it, but I'm going to do a massive overhaul soonish. I aim to take each editor component and turn them into individual plugins. Starting with the script editor and then possibly ending with the map editor last.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Fat Cerberus on April 16, 2013, 02:51:17 pm
I don't know if I would split out the script editor myself--just sounds pointlessly idealistic for no real gain. The main strength of plugins is that you can pick and choose which ones you want to use based on your needs, but I can't think of a single use case where it makes sense to disable the script editor!  ???
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: alpha123 on April 16, 2013, 03:54:32 pm

I don't know if I would split out the script editor myself--just sounds pointlessly idealistic for no real gain. The main strength of plugins is that you can pick and choose which ones you want to use based on your needs, but I can't think of a single use case where it makes sense to disable the script editor!  ???

The reasons would be twofold: one, it would act as a nice test to ensure that the plugin system is sufficiently powerful to handle large plugins with lots of functionality, and two, it would make the core architecture cleaner and easier to maintain.
Oh, and I would disable the script editor, seeing as I use Emacs for all my script editing.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Radnen on April 16, 2013, 07:38:42 pm


I don't know if I would split out the script editor myself--just sounds pointlessly idealistic for no real gain. The main strength of plugins is that you can pick and choose which ones you want to use based on your needs, but I can't think of a single use case where it makes sense to disable the script editor!  ???

The reasons would be twofold: one, it would act as a nice test to ensure that the plugin system is sufficiently powerful to handle large plugins with lots of functionality, and two, it would make the core architecture cleaner and easier to maintain.
Oh, and I would disable the script editor, seeing as I use Emacs for all my script editing.


And someone can then make a plugin that redirects all script files to "Open With..." Emacs, if it can be done. Do you use it standalone or in a shell such as cygwin? Doesn't really matter, it just changes the method of opening a file that's all.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: alpha123 on April 17, 2013, 01:16:36 am

And someone can then make a plugin that redirects all script files to "Open With..." Emacs, if it can be done. Do you use it standalone or in a shell such as cygwin? Doesn't really matter, it just changes the method of opening a file that's all.

Standalone. I will probably make such a plugin, unless I find out some way to embed Emacs in a .NET application (which would be so amazing, but I'm pretty sure it's impossible).

EDIT: Also, Sphere Studio 1.1.4.0 seems to crash as soon as I try to open it (Windows immediate displays that "The Sphere Studio has stopped working" dialog). I didn't have this problem with any prior versions (currently using 1.1.2.0; didn't try 1.1.3.0).
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Flying Jester on April 17, 2013, 01:37:21 am
If you can call unmanaged code from managed code, you probably could embed it.
Title: Re: Radnen's Sphere Studio v1.1.4.0
Post by: Radnen on April 17, 2013, 01:43:08 am
alpha123, I think there was an issue in 1.1.4.0 from the changes I made that required a certain property in the editor.ini (the dockforms property). You can use the editor.ini from 1.1.3.0 and it'll work as intended. In the next 1.1.5.0 this has been fixed thanks to Lord English. I actually think about dropping support for an alternate interface since the Weifen Luo dockpanelsuite has been made Mono-compatible. I'll just use it exclusively for now on.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 17, 2013, 03:52:32 am
Update
Alright, version 1.1.5.0 is up, it contains many small fixes, those of which LordEnglish made and some other notable changes:

- Document searching now uses full filepaths to tell items apart.
- The Alternate Interface has been removed it's 100% DockPanels now.
- Font Importing is now crisp, which is useful for pixel based games.
- Changes to the structure of Editor Forms (to make way for plugins in the future).
- Upgraded the DockPanelSuite to latest version.
- Separate builds for x86 and x64, yes, now there are 64-bit versions starting today. :)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Defiant on April 17, 2013, 02:35:12 pm
@Radnen:

Am I supposed to be able to rename Tasks in the TaskList plugin? I'm getting an error each time I try to edit it. I can set the priority and the type of it, but I can't edit it.

In the dialogue it states: "BeginEdit did not succeed because LabelEdit property is false"

Here's the details of the error:

Quote

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.InvalidOperationException: BeginEdit did not succeed because the LabelEdit property is false.
   at System.Windows.Forms.ListViewItem.BeginEdit()
   at TaskPlugin.TaskList.EditTaskItem_Click(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3643 (GDR.050727-3600)
    CodeBase: file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
Sphere Editor
    Assembly Version: 1.1.5.0
    Win32 Version: 1.1.5.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/Sphere%20Editor.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3645 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3644 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3644 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Sphere.Plugins
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/Sphere.Plugins.DLL
----------------------------------------
WeifenLuo.WinFormsUI.Docking
    Assembly Version: 2.7.0.0
    Win32 Version: 2.7.0.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
TaskPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/Plugins/TaskPlugin.dll
----------------------------------------
ObjectListView
    Assembly Version: 2.5.1.20896
    Win32 Version: 2.5.1.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/ObjectListView.DLL
----------------------------------------
ScintillaNET
    Assembly Version: 2.5.2.0
    Win32 Version: 2.5.2.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/ScintillaNET.DLL
----------------------------------------
System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3082 (QFE.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.


(edit - wrapped error in quote box for easier reading ~neo)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on April 17, 2013, 03:22:31 pm

Update
Alright, version 1.1.5.0 is up....


You'll update the screenshots on the website now, right? ;)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 17, 2013, 03:30:53 pm
Defiant, thank you for spotting that. You can't edit task lists with the drop-down menu anymore, I should have removed that option! You edit all properties by double-click. OLV got rid of the ability to directly open the sub-item editor, so I don't know how to do that via drop-down anymore. I will attach the new plugin here, but it really only removes that item.

N E O, I should do that. :)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 19, 2013, 04:14:00 am
Okay, I'm going to write this as more of a blog piece.

So, I was able to create a plugin of the script editor, but it doesn't work right now. Why? Because making it into a plugin is only a small part of the battle. This just means that I was able to strip away enough of the editor interface so that I can create a separate file and not have conflicts with types, and permissions. This is good, it's an indication of a good design. The next thing to do is make it interactive. And how should I go about that?

Well, the first thing to consider is what exactly I want to make into plugins. Eventually, I want to make all of the core editors as plugins. But most significantly there are three things I do not want to make into plugins, well several things but only three major ones.

1. The project tree.
2. The start page.
3. The menu bar.

The tree is going to be one of the few things 'built' into the editor along with the start page and menu bar. I need the start page because, heck, you could use the editor as a game launcher rather than just an editor, so it makes sense that this basic functionality comes stock. The tree should be there so it can list the file structure of each project when you open it. But it will not be able to open the individual art and script files (we'll get to that later). Lastly, the menu bar needs to be stock. There are a few menu options that will come with the editor. The rest shall be added by plugins as they are loaded.

With that out of the way, how is it that we can turn the script plugin into a full functioning piece of software? Well, the answer is in the utilization of the menu bar and the project tree. The host program would introduce methods to register a filetype to a plugin. The filetype is registered with the project tree view, so that when you double click a file, it looks up it's filetype and then launches the code necessary to add that file into an editor object and then that editor object into the main dock panel of the host. The menu bar is also registered to, but differently. The plugin registers to it a menu item that when clicked will begin the process of saving/loading/creating new documents of the editor.

The next problem is how free and open I make this API. If I give full access to the menu bar a user could accidentally destroy the menu bar when their plugin deactivates. But if I give too less freedom, then it might get hard to add custom commands to the menu bar. So, I think a plugin will allow you to manage your own menu item and add/remove that item from the menu bar. There's one caveat, adding your item to the menu bar will also add any necessary sub-menu's that are required to fully realize the menu item. What if you add a script sub-menu and in it a sub-menu for tab control? If I remove the tab-control item, it will not destroy the sub-menu for the tab control items. The fear here is what happens when another plugin extends the features of one plugin? This is possible, and so I think when registration occurs each menu item would need to be tagged with the plugin it comes from.

Currently, deactivation of a plugin can look like a mess. What if there was an easier way to deactivate? Activation would have to be a bit more involved since it requires the construction of items and placements, but once those features are added they should be easily removed. So, I'm thinking that each menu item and registered filetype contains a tag to the plugin that added it. Then when deactivated the host program does the heavy-lifting of searching for and destroying any references to that plugin.

And so, now I'm left with implementing this final, but crucial part.

Finally, I also intend to make the plugin list itself accessible by individual plugins. This way a plugin can search for a dependent plugin and then warn the user if the dependent plugin has not been installed. A map editor may require the use of a script editor. But why reinvent a script editor if it could just use one already provided by a plugin? Furthermore a plugin that extends another plugin may then be possible. A plugin just has to provide the API that another plugin must use to interact with it. So, in a way I can see a leap-frogging of plugins occur. But I must make it user friendly, with a sensible API. I don't want plugin creation to be too tedious or it would not be easy to have fun creating your own additions, etc.

I would therefore have to construct a tutorial as well. Possibly start a new github repo solely intended for the construction of editor plugins, utilizing the Sphere.Core and Sphere.Plugin API's.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Defiant on April 19, 2013, 08:55:29 pm
Is the image editor complete? I was going to sift through the topic but then I got a little lazy. Anyway, I can't seem to zoom in/out  on an image. Interesting to note is that zooming in/out works in the map editor. So I'm not too sure what the issue is.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 19, 2013, 09:06:02 pm
The image editor doesn't zoom anymore. I got rid of that, but have the intention of bringing it back someday (I wanted to use a better method for zooming, the method I use on the map editor). Currently it auto-zooms with the size of the editing field - just like how the old editor does it. I made sure to at least fall back on the old editors behavior. The menu items well, are misleading I should gray them out.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 20, 2013, 06:10:32 am
Update
The Script Plugin is now live! I have been able to make it load up and edit files. My next task is to fully remove it's functionality from the editor. For example, there are many menu options that it still relies on. Menu options that the plugin must now implement.

So, I have two plugin interfaces now:
1. IPlugin
2. IEditorPlugin

The difference is, IEditorPlugin adds an additional contract: you must have made use of the EditorObject component. If you do not, then it is not an editor plugin. The task list is not an editor plugin, so does not use IEditorPlugin, but the Script Editor is an EditorObject and so must make use of it. Now, IEditorPlugin makes use of interface inheritance. That means, it must also have you implement all of IPlugin as well. The neat trick here, is that the IPluginHost can cast between IPlugin and IEditorPlugin whenever it can. That means IPlugin is all that needs to be relied on. The only limitation is that it's the hosts job to cast between the types so sadly it must know that beforehand which means you can't create your own plugin on the fly. But have no fear, I'll be developing various interfaces to facilitate the need to have subplugins and so on.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on April 20, 2013, 11:00:34 am

The neat trick here, is that the IPluginHost can cast between IPlugin and IEditorPlugin whenever it can. That means IPlugin is all that needs to be relied on. The only limitation is that it's the hosts job to cast between the types so sadly it must know that beforehand which means you can't create your own plugin on the fly. But have no fear, I'll be developing various interfaces to facilitate the need to have subplugins and so on.


Egh, this usage of casting is very hackish if I'm understanding it right, and having the host need to be pre-programmed to know which plugins are which types is very ugly, and actually destroys most of the advantages of having plugins in the first place.  There must be a cleaner way to do this...

Also Radnen, I sent you a pull request to fix the x86/x64 build options (all the projects weren't being built), want to check it out for me?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 20, 2013, 03:02:51 pm

Egh, this usage of casting is very hackish if I'm understanding it right, and having the host need to be pre-programmed to know which plugins are which types is very ugly, and actually destroys most of the advantages of having plugins in the first place.  There must be a cleaner way to do this...


I could have just the one IPlugin interface, and it would have been pre-programmed to know things about it anyways. The only difference here is organizational. I don't know of a cleaner way. Basically, you must register to the project tree the filetypes and the plugin that loads those filetypes (Script Editor and .js files). When you double-click an item in the project tree (a script file ".js") it must open it as if it were an EditorObject (Script Editor implements EditorObject). If the plugin was an IEditorPlugin beforehand, then it knows absolutely that it implements an EditorObject and assumes it's safe to use. Not all IPlugins have EditorObjects, but all IEditorPlugins do. I think this is a great and safe method for figuring that out.

There is never full access to the host. A plugin must always speak through an API for the host to do things (like making a game in Sphere). The IEditorPlugin is just another way of talking to the host. I don't know if it's possible to create whatever plugin you want to make, it still comes down to a limited API. If I don't offer a way to change the title of the editor form, then there's no way of doing it, for example. Because of this, I see no disadvantage to the IEditorPlugin/IPlugin inheritance. At one point the host has to know things about the plugin. It's part of the entire plugin implementation.


Also Radnen, I sent you a pull request to fix the x86/x64 build options (all the projects weren't being built), want to check it out for me?


Hmm, you even got rid of the old task list stuff. I guess it's safe to move forward on this.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 21, 2013, 08:39:53 pm
Update
I have finished the Script Plugin. I think it does everything that it did before. Just that it's now all contained as a plugin. I have not released the latest edition of the editor, but I think I should soon, but I want more plugins to be converted.

I'm wondering what people think of the plugin API so far:

- The host: https://github.com/Radnen/spherestudio/blob/master/Sphere.Plugins/IPluginHost.cs
- The plugin: https://github.com/Radnen/spherestudio/blob/master/Sphere.Plugins/IPlugin.cs
- The EditorPlugin: https://github.com/Radnen/spherestudio/blob/master/Sphere.Plugins/IEditorPlugin.cs
- The Task Plugin: https://github.com/Radnen/spherestudio/blob/master/TaskPlugin/TaskPlugin.cs
- The Script Plugin: https://github.com/Radnen/spherestudio/blob/master/ScriptPlugin/ScriptPlugin.cs

Is it too hard to understand? What do you think could make it easier? I just want general input. Because since I was able to fully implement the script editor into the Sphere Studio with this API, I think it's more or less right where it's going to be. I can't think of much more to add, but something might pop up.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on April 22, 2013, 03:34:29 pm
I forget, does C# have implicit variable casting? I wonder if there could be a float/double Version property or if strings can be cast as float/double so that comparisons can be made for plugin updating from an online source and such. I know the open-source RetroArch (http://www.libretro.org/) (especially the GUI front-end) is really good about that.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on April 22, 2013, 03:44:43 pm
By default, widening conversions (float to double, int to long, etc.) are implicit; any conversion that could lose information, however, must be cast explicitly.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 22, 2013, 03:46:38 pm

I forget, does C# have implicit variable casting?


Yes and no. If the type were 'var' (like in JS) it is weakly typed and will implicitly cast between strings, integers, etc. As it stands the version is a string and must be parsed between boolean, integer, etc. Do you think it should be changed to a float? Because I was thinking of using a 3 point versioning system with an indicator for alpha.beta builds: for example, "v1.2.5a" would be a valid string, and so would "1.2". The former not so much a floating point type number, while the latter is.

Edit: And Lord English is right too. :)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on April 22, 2013, 04:37:07 pm


I forget, does C# have implicit variable casting?


If the type were 'var' (like in JS) it is weakly typed and will implicitly cast between strings, integers, etc.


This is incorrect, all variables in C# are strongly typed, var merely instructs the compiler to figure out the type itself based on the rvalue instead of explicitly specifying it.  So if you do:
Code: (csharp) [Select]
var foo = "maggie ate it";


foo is then defined to be a string variable. You can't later assign a different type of value to it, the compiler will give you an error.  I think you're thinking of dynamic, which is a different beast entirely (used to implement duck typing).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 22, 2013, 05:03:14 pm
Oh! Well, I don't use it much anyways. I thought it had similar properties as the JS var, I should have probably tested it out a bit. :-[
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on April 22, 2013, 05:14:16 pm
Yeah, its main purpose is so that you can do stuff like this:
Code: (csharp) [Select]
var dict = new Dictionary<string, ReallyLongGenericName<SomeType, SomeOtherType> >();


Obviously that was an exaggeration, but yeah, the variable is still strongly typed, it just makes the declaration cleaner when using complicated types.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Flying Jester on April 22, 2013, 05:23:08 pm
So it's like a C++ 'auto'.

The C++ 'auto' is a Bad Thing (tm).

From what I know of C#, that would lead me to believe the C# 'var' is a worse thing.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on April 22, 2013, 05:29:29 pm
Huh? auto in C++ merely specifies a local variable, and is the default if not specified anyway. Unless they changed the meaning in C++11?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: alpha123 on April 22, 2013, 05:57:48 pm

Huh? auto in C++ merely specifies a local variable, and is the default if not specified anyway. Unless they changed the meaning in C++11?

It changed in C++11 to do type inference.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Flying Jester on April 22, 2013, 05:59:41 pm
Yes, I mean in C++11. Where it went from meaning nothing to meaning anything at all.

Not exactly an improvement.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: alpha123 on April 22, 2013, 06:01:33 pm

Yes, I mean in C++11. Where it went from meaning nothing to meaning anything at all.

Not exactly an improvement.

Huge improvement. Type inference is great. If the compiler can figure out the type of my variable, why do I have to specify it?

BTW, Raden, I'm getting an exception when trying to create a new spriteset (although it otherwise functions properly; i.e. the spriteset is actually created). See http://pastebin.com/nNPRQtSn (http://pastebin.com/nNPRQtSn).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 22, 2013, 07:34:35 pm
Alright, it's been fixed. I'm surprised such an error would be present for so long! Gosh, I remember making spritesets in my Sphere Editor all the time. And to think that code file had never been modified for a long time. Weird.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on April 23, 2013, 01:49:51 pm
I'm getting a NullReferenceException when enabling the task list plugin in the options, the Visual Studio debugger highlights the Plugin.Initialize call in PluginWrapper.cs at the time of the error, but checking the call stack and variables, everything looks okay so I'm not sure what's going on.  Any chance you could check this out?

Edit: Nevermind, I figured it out. It was trying to read a property from CurrentGame, but if no project is loaded, CurrentGame is null.  It's fixed now.  I also fixed the references so the most recently-built copy of the plugins is used all the time, without having to manually add the DLLs to the VS project tree.  Should make debugging plugins easier now, as well.

Edit 2: Really weird bug in the script editor, I don't even know where to begin looking for this one: With the new script plugin, Ctrl+V (or Edit->Paste) seems to paste the text into a new Untitled file instead of into the current script.  Really strange behavior.  The only way I was able to paste was to right-click the Scintilla control itself.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 23, 2013, 07:37:32 pm

Edit: Nevermind, I figured it out. It was trying to read a property from CurrentGame, but if no project is loaded, CurrentGame is null.  It's fixed now.  I also fixed the references so the most recently-built copy of the plugins is used all the time, without having to manually add the DLLs to the VS project tree.  Should make debugging plugins easier now, as well.


I hate null reference errors, they always creep up! Anyways, yes in the documentation for CurrentGame, it is either the currently loaded game or null - null implying there's no game loaded!


Edit 2: Really weird bug in the script editor, I don't even know where to begin looking for this one: With the new script plugin, Ctrl+V (or Edit->Paste) seems to paste the text into a new Untitled file instead of into the current script.  Really strange behavior.  The only way I was able to paste was to right-click the Scintilla control itself.


That has to do with the extra logic for figuring out pasting. I think I muddled something up when making the switch to plugins. For images, it was to open a new image editor with the pasted document. For text, it was to open a script editor. But, the script editor is now a plugin, and although it should have pasted into the CurrentEditor object, it got confused. I'll fix this soon, good catch.

Edit: Finished the hotfix.

One thing about the way you are copying over plugins: Good idea, but that relies on plugins having to end with the word 'Plugin'. For now I'm doing this, and I guess for the initial plugins that come with the editor this is fine. Plugin's don't have to end with the word 'Plugin', but that's just a minor point.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Flying Jester on April 24, 2013, 05:43:38 am
I assume that at some point Sphere Studio won't error out when there exist dlls in the plugins directory that don't work as plugins, too?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on April 24, 2013, 08:36:41 am

One thing about the way you are copying over plugins: Good idea, but that relies on plugins having to end with the word 'Plugin'. For now I'm doing this, and I guess for the initial plugins that come with the editor this is fine. Plugin's don't have to end with the word 'Plugin', but that's just a minor point.


Yeah, I figured that.  I suppose you can always edit the build settings later if needed (Project properties -> Build Events).  Right now all the default plugins DO end in "Plugin" so it was the simplest way to get it to move all the DLLs at once. The main point behind it was so you always have the latest build of all your plugins for debugging, and you also get the correct build for x86/x64 and release/debug without having do a manual file-copy dance all the time.  When using Visual Studio, I tend to prefer having the IDE do as much manual labor for me as possible. :)

Edit: Bug I found: The Save button on the toolbar is permanently grayed out ever since you implemented the script plugin.  Not a big deal as File->Save and Ctrl+S still work, but might confuse new users.  Oh, and I discovered an old Thumbs.db in the repo (only found it because Windows had changed my copy and git wanted to commit it even though it was in .gitignore, stupid git bug), but it'd be ridiculous to create a pull request just for something so trivial, so I guess you can delete it yourself if you feel like it. :)

Oh, one more thing: I tried to move the audio player to a plugin myself using the script editor as a basis, but got confused as hell by the plugin API.  I couldn't figure out what was part of the plugin architecture and what was part of the script editor itself.  Any chance you could mock up some documentation for the plugin API?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on April 24, 2013, 01:53:37 pm

Edit: Bug I found: The Save button on the toolbar is permanently grayed out ever since you implemented the script plugin.  Not a big deal as File->Save and Ctrl+S still work, but might confuse new users.  Oh, and I discovered an old Thumbs.db in the repo (only found it because Windows had changed my copy and git wanted to commit it even though it was in .gitignore, stupid git bug), but it'd be ridiculous to create a pull request just for something so trivial, so I guess you can delete it yourself if you feel like it. :)


Noted.


Oh, one more thing: I tried to move the audio player to a plugin myself using the script editor as a basis, but got confused as hell by the plugin API.  I couldn't figure out what was part of the plugin architecture and what was part of the script editor itself.  Any chance you could mock up some documentation for the plugin API?


Yeah, I'll put up some documentation on the github wiki. The Script Editor turned out a bit messy since there was so many menu items to add.

Edit:
Here is a tutorial on plugin creation: https://github.com/Radnen/spherestudio/wiki/How-to:-Plugins

I've also added the dummy 'MyPlugin' to the github source. But when I build that plugin it does not copy it to the /Plugins path. I have to manually copy it, despite it ending in 'Plugin'. Is there something else I have to do? Anyways, it will serve as an example on how to create custom plugins.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 01, 2013, 01:46:12 am
So thanks to your plugin tutorial (I'm a hands-on type of person so I didn't even check the wiki page, just opened up the MyPlugin project and went from there, thanks for making that! :) ) I managed to implement an audio player, but I went in a decidedly different direction to the existing player: "Sound Test", styled after the Sound Test modes from the old Kirby games.  Basically it adds a tab to the sidebar which lists all the music tracks and sounds in your project and lets you double-click one to play it without leaving your current map/script/whatever.  Much better, I think, than opening a separate document window for audio. This interrupts your work, however briefly; losing your train of thought is never fun!

I opened a pull request to merge it in, that's been open for a few days now I think and thanks to my perfectionism has accumulated a total of 7 commits...  and I think there might have been a hotfix for the editor in there as well, don't remember.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 01, 2013, 04:44:22 am
I have not really edited the editor since my last commit, so your changes would be easy to merge. Of course, if I want to even merge it. I intend for people to make plugins separately from the editor. And so I may end up creating another repository for editor plugins. Perhaps get N E O to set one up among the official sphere repo's on github.

I'm very happy that you made a plugin! Now there will be varying authors among the plugins. Tell me, what part of the process needs improving? What more access do you want (to the Host)? Did you find out how to read/write to the editor settings? Because I supply an editor settings object for you to read from / edit. You were using a more or less incomplete plugin API to do this, so granted that later on there should be more stuff: such as sub-plugins.

Edit: What changes to the editor did you do? Or were they all plugin related. Furthermore, one thing that can help you (that I haven't yet added) is an 'about to play game' event that you can hook onto. That way you can pause all playing music/sounds when you play-test the game.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 01, 2013, 05:01:25 am
I had a feeling you'd have reservations, but I intended for the Sound Test to be a full replacement for the existing audio player, a component I consider an integral part of a default game-making IDE along with the script and map editor, that's the only reason I proposed a merge.  There's a few other changes I'd have to make to it to meet that goal (registering the proper file types for one!), but that was the intent.

As for the editor fix, it turns out it was just a quick hotfix to move the Open Last Project code AFTER plugin evaluation so that plugins get an OpenProject event for it.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 01, 2013, 05:07:16 am
I guess if you round it out, I'll add it as an official plugin. But after that, I really want to develop a toolkit that people and go download and use. It'll contain the test "MyPlugin" code, and the dependencies that it needs: dockpanelsuite, Sphere.Core, and Sphere.Plugins. From there the user can then build their own custom plugin away from the editor. Because having the editor code is a bit like cheating, since in the end, you can only talk to it via the Host API.

In your case you can spot bugs and fix them, :P
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 01, 2013, 05:21:57 am
If I had to suggest one change to the plugin API, it would be to remove the explicit dependency on dockpanelsuite.  That's the one big thing that bugs me, since if in the future you decided to use a different, better GUI library (unlikely but it could happen), ALL existing plugins would break. That's the hardest part about designing a plugin API: You want it to be stable. Not like Firefox extensions where half of them break with every new release!

And not only that, but forcing the plugin author to create their own DockContent object means it'll be a lot more difficult to eventually implement saving the docking layout...

Other than that, no real issues with the plugin API, except maybe that you could redesign the IEditorPlugin interface to not inherit from IPlugin. Seems counter to the way interfaces are normally used. The contract shouldn't be "editor plugins implement IEditorPlugin", it should instead be "editor plugins implement IPlugin AND ISphereEditor".  Something to think about. :)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 01, 2013, 08:00:45 am
All right, I finalized the Sound Test plugin.  The only thing I couldn't do was register filetypes to it, since that apparently requires an IEditorPlugin implementation.  Oh well.  I just pushed one last commit into the pull request, your call now if you want to merge it.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on May 01, 2013, 12:26:41 pm
I intend for people to make plugins separately from the editor. And so I may end up creating another repository for editor plugins. Perhaps get N E O to set one up among the official sphere repo's on github.


Done (https://github.com/sphere-group/sphere-studio-plugins)! Right now Radnen and Bruce/Lord English have push+pull access to the repo; anyone else let me know if/when you want to have push access, otherwise follow the usual GitHub pull request procedure.

@Radnen - eventually, once Sphere Studio finally supplants the original editor I'd like to see it become the official editor for now and would recommend eventually transitioning the repo over to sphere-group under the repo name sphere-studio (the hyphen for consistency with the other repos). You could move it, refork it back to you, do all your updating on your version, then merge with the sphere-group version once tested. How does that sound?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 01, 2013, 12:35:56 pm
@Radnen -
Just added another commit.  I implemented the TestGame event you suggested above (good idea!), so now Sound Test automatically pauses any playing music when you click the Test Game button.

Don't get mad at me, but I also renamed the events.  Events aren't supposed to start with 'On', that's the naming convention for the overridable protected method that raises the event (if one exists).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 01, 2013, 01:44:29 pm

If I had to suggest one change to the plugin API, it would be to remove the explicit dependency on dockpanelsuite.  That's the one big thing that bugs me, since if in the future you decided to use a different, better GUI library (unlikely but it could happen), ALL existing plugins would break. That's the hardest part about designing a plugin API: You want it to be stable. Not like Firefox extensions where half of them break with every new release!


Yeah, thinking about it, you are right. But the only other issue is then creating an abstraction layer between the plugin API and editor. I need some way for the user to do their styling away from the dockpanel API that is also consistent with it and not to specific to it either. Hmm...


And not only that, but forcing the plugin author to create their own DockContent object means it'll be a lot more difficult to eventually implement saving the docking layout...


This is going to be a harder problem to solve anyways. Suppose you have plugins activated all over, then delete your editor.ini file but not the spheredock.xml file. It'll attempt to dock objects that it cannot access. I guess it could just silently fail for those. But then trying to reposition them if they do exist may take some other data. I'll have to look into that.


Other than that, no real issues with the plugin API, except maybe that you could redesign the IEditorPlugin interface to not inherit from IPlugin. Seems counter to the way interfaces are normally used. The contract shouldn't be "editor plugins implement IEditorPlugin", it should instead be "editor plugins implement IPlugin AND ISphereEditor".  Something to think about. :)


Oh I've thought about that, and inheritance among interfaces is a good way to go for something like this. But you are also right, there's been whole debates! But apparently MS had an idea good or not to include interface inheritance. The idea of multiple interface inheritance is not really all that cool.


All right, I finalized the Sound Test plugin.  The only thing I couldn't do was register filetypes to it, since that apparently requires an IEditorPlugin implementation.  Oh well.  I just pushed one last commit into the pull request, your call now if you want to merge it.


The file registration is only for double-clicking filenames in the project tree. I'm thinking of perhaps a better way to register filetypes. So that custom events happen when clicking on certain filetypes. Which means, I might actually be able to get rid of IEditorPlugin altogether. (You do the work of determining if you attach an editor object or not to the Sphere Studio) which is what I ideally wanted anyways.


Don't get mad at me, but I also renamed the events.  Events aren't supposed to start with 'On', that's the naming convention for the overridable protected method that raises the event (if one exists).


No, it's fine. I rename things all the time. I just had the habit of using 'On' for events, but they probably shouldn't use that. (Just, uh, tell me what you renamed so I can find things).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 02, 2013, 06:29:23 pm


Don't get mad at me, but I also renamed the events.  Events aren't supposed to start with 'On', that's the naming convention for the overridable protected method that raises the event (if one exists).


No, it's fine. I rename things all the time. I just had the habit of using 'On' for events, but they probably shouldn't use that. (Just, uh, tell me what you renamed so I can find things).


All right, OnOpenProject is now called LoadProject, OnCloseProject is now UnloadProject.  And the new one I added at your suggestion is TestGame.  Since these are part of the public plugin API, I figured it was best to stick to the same naming conventions as WinForms uses, to minimize confusion.

As for multiple inheritance of interfaces, I don't really have an issue with it.  An interface is not a class, but a contract.  Multiple class inheritance doesn't make much sense (one of the dumber features of C++ if you ask me, and complex as hell--I'd hate to have to write a C++ compiler!), but there's nothing wrong with "signing" two different contracts. :)  I suppose you could make the case that IEditorPlugin is a subcontract of IPlugin (i.e. to extend the metaphor, you can't sign the latter contract without first signing the former), but I don't know, the setup still bugs me, I can't put my finger on why...

Edit: Hmm, seems I somehow missed your idea about custom events for file types.  That's a good idea, mind if I try my hand at implementing that? :)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 02, 2013, 07:31:13 pm

Edit: Hmm, seems I somehow missed your idea about custom events for file types.  That's a good idea, mind if I try my hand at implementing that? :)


Sure, I'm super busy, as you can tell, I haven't really touched the repo for a while.

Anyways the idea is to create an event that is triggered when someone double-clicks an entry in the project tree. I think you should develop a custom EventArgs that stores the filename that was clicked. Then it's up to the plugin's callback that will be passed to the event to determine if it should or should not open a file of that type. This basically offloads type checking onto the plugin creator than the editor, but it gives more freedom.

This also completely removes filetype registration. But this method can be slower. Since if 8 plugins add 'listeners' to the event handle, then 8 functions are triggered, each checking if they can open that filetype. If there is a match, well, it would be weird but it is possible that two plugins can attempt to open the same filetype. The original idea of the registry was to avoid this.

There is a more complex path that is a hybrid of the registry and the event versions. You sign on to the registry what types a plugin can open, then when the user double clicks, send out only the event for that particular filetype. In this way, there's a 1:1 relationship with plugins and filetypes, and only a single event is triggered when the user double-clicks a file, rather than 'n' amount.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 03, 2013, 01:48:51 am
All right, done.  Works wonderfully, Sound Test even plays stuff right from the tree now.  I think I may have had a bit too much fun with this though... check the commit descriptions and diffs if you don't believe me.  :D
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 03, 2013, 04:16:09 am
Cool, I merged the rquest. I'm getting a cross-thread issues when testing the editor with music playing:

Quote

Cross-thread operation not valid: Control 'SoundPicker' accessed from a thread other than the thread it was created on.


On line 134 of sound picker.

Woah, and this line of code is amazing:
Code: (csharp) [Select]

dirInfo.GetFiles(searchFilter, SearchOption.AllDirectories);


I did all of my recursive directory searches by hand, huh, never would have thought .NET would/could do this for you.

Edit:
I cleaned up your code file. Um, it suffered from some complexity issues that made the code hard to read. >.<
Don't fear, the changes are minor and stylizes it in such a way that it resembles (for the most part) other portions of the editor. I don't like using 'this' everywhere and I usually put an '_' underscore prior to a private field. I also use a lowercase letter such as 'm', but I did not choose to use that style for this project. I hope you don't mind.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 03, 2013, 09:10:02 am

Cool, I merged the rquest. I'm getting a cross-thread issues when testing the editor with music playing:

Quote

Cross-thread operation not valid: Control 'SoundPicker' accessed from a thread other than the thread it was created on.


On line 134 of sound picker.


Odd, I never had any issues like that and I was constantly playing music and changing tracks throughout my testing just to stress test the thing.  I didn't think the editor was multithreaded though, that's a really weird error. ???

Quote
Woah, and this line of code is amazing:
Code: (csharp) [Select]

dirInfo.GetFiles(searchFilter, SearchOption.AllDirectories);


I did all of my recursive directory searches by hand, huh, never would have thought .NET would/could do this for you.


That's why I love the .NET Framework. 9 times out of 10 the framework will do the manual labor for you, you just have to go deep enough. (Inception reference... okay that was terrible, don't shoot me please :-X).  If you've ever heard the framework described as "the mother of all dependencies", this kind of thing is the reason why. ;D

Quote
Edit:
I cleaned up your code file. Um, it suffered from some complexity issues that made the code hard to read. >.<
Don't fear, the changes are minor and stylizes it in such a way that it resembles (for the most part) other portions of the editor. I don't like using 'this' everywhere and I usually put an '_' underscore prior to a private field. I also use a lowercase letter such as 'm', but I did not choose to use that style for this project. I hope you don't mind.


I guess that's okay.  It's just that I don't like not qualifying references to instance variables, since that can cause problems if you're not careful--for example, if you have a local variable with the same name as a private field, when you assign to it which one are you referring to?  The compiler could probably figure it out, but someone reading the code may not be able to at a glance (I'm a big advocate for self-documenting code). And naming instance variables with conventions like 'm_' etc. I feel is hackish when the language already has a method built-in (this) to resolve the ambiguity. You're already referring to instance fields as obj.something from outside code, why should it be any different on the inside?  But yeah, it's an official plugin now, might as well keep things consistent.

For what it's worth though, I find the "cleaned-up" code harder to read than the original version. I see the underscores, yet I have to keep reminding myself "Underscore, okay, this is an instance field, not a variable"--it's not as instinctive as when I see 'this.fieldName', if I see that then I immediately know where to look for a declaration.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 03, 2013, 01:18:35 pm

I guess that's okay.  It's just that I don't like not qualifying references to instance variables, since that can cause problems if you're not careful--for example, if you have a local variable with the same name as a private field, when you assign to it which one are you referring to?  The compiler could probably figure it out, but someone reading the code may not be able to at a glance (I'm a big advocate for self-documenting code). And naming instance variables with conventions like 'm_' etc. I feel is hackish when the language already has a method built-in (this) to resolve the ambiguity. You're already referring to instance fields as obj.something from outside code, why should it be any different on the inside?  But yeah, it's an official plugin now, might as well keep things consistent.

For what it's worth though, I find the "cleaned-up" code harder to read than the original version. I see the underscores, yet I have to keep reminding myself "Underscore, okay, this is an instance field, not a variable"--it's not as instinctive as when I see 'this.fieldName', if I see that then I immediately know where to look for a declaration.


I understand, but I still think it's largely a stylistic issue. You have made an official plugin for the Sphere Editor, and so it should be styled like everything else. If you made it so it would be apart from the editor, I wouldn't mind. Your issues with the convention are, well, due to the fact you are not really used to my code style. When I go online I see many ways of code styling's and each one is a bit different, so this is a problem that I have too. Not everybody uses 'this', and not everybody uses a private field convention, and if they do it's very different from other peoples code.

Personally I don't use 'this' because it's more to type, it adds a lot of blue around the screen, makes long lines longer, and I know what the instance fields were. Very rarely does an instance field equal a local variable, usually in the constructor function this happens or setter functions. I use an '_' underscore because I have grown to read that as a private instance field, same with other conventions such as 'm_', etc. So, as I said it's really just a style preference.

It would be cool someday to work on an open source project with multiple authors and the IDE styles the code to everyone's preference when the file is open, then styles it to a project default when it closes. :P
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 03, 2013, 02:15:09 pm
I tend to view the situation this way: You have an open source project on GitHub, anyone can fork the project, make edits and request a merge. While you might know that, say, _fileTypes is an instance field, a new developer looking at a method referencing it won't know that right away (especially if their preferred style is different as in my case) and could introduce bugs, e.g. thinking the variable is local and modifying it--now your state is invalid).  Some such bugs will be obvious in the diffs, but others could be harder to spot.

I won't object any further (and you'll see in my latest edits I tried to stick to your style), but if I had to make one suggestion it'd be to add some documentation to the repo saying what the coding conventions are for the project.  Most large projects have a document like this, so that you can direct new contributors to it before they make any edits.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 03, 2013, 03:23:23 pm
I have added a stylesheet to the wiki, and modified the wiki for first time users and developers.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 03, 2013, 03:49:47 pm
So are there any other features you wanted to implement? If they're not too much trouble I'll see if I can do them. I do want to get back to working on Spectacles though, so nothing too involved.

Good that you added stuff to the wiki, I'll check it out. :). Also, I think we should take any further discussion on editor coding into PM. I've kind of derailed the thread beyond all recognition, it was just supposed to be for feature requests and bug reports! :-[
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on May 03, 2013, 05:19:57 pm
Keep in mind that a plugin repo now exists (https://github.com/sphere-group/sphere-studio-plugins), so you can commit 3rd-party plugins to it now.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 03, 2013, 05:51:17 pm
@NEO
Yeah, I've been holding off on making more plugins until the plugin API is a bit more stable.  My past few additions have changed it quite a bit.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 03, 2013, 06:33:02 pm
The API will continue to change until I feel it's good enough to do everything I would like it to do.

NEO: the plugin repo is good for user made plugins. The ones here are the stock plugins. They will release with the editor so that people who first download it have tools to use.

Bruce: I found it, I found why the thread error is happening. The filewatcher is doing it. It runs on its own thread, of course! I don't know why, the project tree does the same thing. Weird...

I think I fixed the problem but it won't build, due to an 'incorrect format' issue with the IrrKlang library. I have seen this before, and it's a bug in MSVC with .resx files that causes it. Because I know for a fact everything checks out. The problem is fixed by using the filesystemwatcher from the toolbox and placing it into the control. This internally sets it so that it can invoke code used in it's parent control. This resolves the cross-thread issues. However, it also mucks up the .resx file in such a way that it can no longer compile on my machine.

Edit2:
Problem solved with a delegate and thread-safe invoking. (this does not require the modification of the .resx file).

Edit3:
Shit, I can't make any change to the .resx file of the sound test plugin's main control. What the hell? As soon as I modify a property in a control in the editor for the sound test plugin, I cannot compile due to an invalid format issue with IrrKlang. What's wrong with the .resx file for the sound test? I know it's not you Bruce, weird. Keeping it the way it is makes it work. Ugh. I've had this issue once before. I think I had to completely delete the control and rebuild it from scratch. But I do not want to do that to your otherwise nicely working plugin. Do you use VS2010 or 2012?

Edit4:
It's a bug when compiling against .Net 2.0. .net 4.0 will fix this problem. Visual Studio will attempt to encode things in base64 even when compiling for an x86 machine. But the error was only for image lists... Which you are using.

Edit5:
Fixed by removing your image list.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 03, 2013, 11:01:53 pm
I use VS2012 Express (Express is one IDE now, not one per language as in old versions).  The .resx/image list issue must be a bug fixed in the new version, because I compile for x86 all the time and never had any issues.  The only thing that's a pain about me using 2012 and you the older version is that sometimes VS2012 rewrites the solution file and then I have to manually edit the header so that VS2010 will open it.  This was braindead design on MS's part, since the solution format is otherwise identical other than the header.

Base64 has nothing to do with x86/x64 though, it simply means it encodes the binary data (normally base-256) as base-64 numbers, which can be mapped easily to only ASCII characters.

I would recommend upgrading to VS2012, though, it fixes a lot of bugs that existed in 2010.  Any reason you're still using .NET 2.0 though?  I assume for compatibility reasons, but that doesn't really help since Win8 doesn't actually include .NET 2.0 or 3.x (it automatically prompts the user the first time they run an app requiring these versions, but it still takes 10 minutes to download and install), only 4.0 and 4.5.  .NET 4.0 will install on XP, no reason you couldn't target that at this point.  Either way, somebody is going to have to download a framework.  And in .NET 4 you'd get some nice new features, such as LINQ.  I don't know if you have any exposure to LINQ, but it's basically awesome.  You can do stuff like this:

Code: (csharp) [Select]
var enemyUnits = from unit in battleUnits where unit.type == "enemy" select unit;
foreach (BattleUnit enemy in enemyUnits) {
    // ...
}


I don't know if I have the syntax exactly right, but that's the basic idea, the ability to do an SQL-style query against any collection in your program.  Something that would be awesome to have access to when developing an IDE, I think. ;D
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 03, 2013, 11:08:52 pm
I know LINQ quite well. :)

The reason to keep it at .net 2.0 was twofold:
1) High support, very versatile, supported by Mono (well, now Mono is 4.0 compatible), and Wine
2) Dockpanelsuite is for .net 2.0 (but I think it might be for 4.0 now).

Obviously time has changed since starting the project, I think moving to 4.0 is a lot better now. It also has a native way of supporting plugins. I should also get VS2012, since I basically get it for FREE from my college. :) I'm running VS2010 pro right now, and dang was it good. But now 2012 is out and I was reluctant to try it until bugs were fixed. I think now's a good time to switch over, though.

Just so you know, I've used 4.0 in many, many other projects. ;)


Base64 has nothing to do with x86/x64 though, it simply means it encodes the binary data (normally base-256) as base-64 numbers, which can be mapped easily to only ASCII characters.


Oh, I thought due to the discussion here: http://stackoverflow.com/questions/2992075/could-not-load-file-or-assembly-or-one-of-its-dependencies-an-attempt-was-m that the base had something to do with the environment. I guess I was wrong.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 03, 2013, 11:16:26 pm
I think you killed the sound test plugin.  I'm getting directory not found exceptions now on launch...

I see what it is, you're trying to manually search the "sounds" and "music" directories (the latter of which doesn't exist).  That's why I just had it search the whole project recursively, this way it picks up files whereever they happen to be.  The Sphere engine itself doesn't really care where you put stuff, so I figured the editor and plugins shouldn't either in most cases.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: alpha123 on May 03, 2013, 11:56:00 pm

I don't know if you have any exposure to LINQ, but it's basically awesome.  You can do stuff like this:

Code: (csharp) [Select]
var enemyUnits = from unit in battleUnits where unit.type == "enemy" select unit;
foreach (BattleUnit enemy in enemyUnits) {
    // ...
}


The first thing I noticed is the similarity with Common Lisp:
Code: (lisp) [Select]

(loop for unit in battle-units when (eql (unit-type unit) :enemy) do
   (do-stuff-with unit))

Cool.

I'm glad C# programmers get something like this. Why Microsoft didn't settle for filter/map/reduce methods, I'll probably never know. Haskell, ML, Common Lisp, Ruby, Python, Perl, JavaScript, Erlang, and probably a lot of others have had this sort of thing for a while, just under the admittedly somewhat intimidating name of higher-order functions.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 04, 2013, 12:02:49 am
Eesh, Lisp code always makes my head spin.  I mean, I can kind of figure out what it does if I study it hard enough, but I don't find it intuitive to read at all.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: alpha123 on May 04, 2013, 12:20:35 am
I'll definitely admit Lisp can be kind of write-only at times. There are good ways to right it and bad ways to write it. It also takes a lot of getting used to.

Controversial opinion: A language you can't write unreadable code in is a bad language. If a language doesn't give you freedom to write terrible code, it can't give you power to write beautiful code.

Anyway, the similarity just made me wonder if LINQ was inspired by Common Lisp's loop feature (which is both loved and hated among Lispers; I'm of the opinion it's pretty awesome).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on May 04, 2013, 01:35:57 am


I don't know if you have any exposure to LINQ, but it's basically awesome.  You can do stuff like this:

Code: (csharp) [Select]
var enemyUnits = from unit in battleUnits where unit.type == "enemy" select unit;
foreach (BattleUnit enemy in enemyUnits) {
    // ...
}


The first thing I noticed is the similarity with Common Lisp:
Code: (lisp) [Select]

(loop for unit in battle-units when (eql (unit-type unit) :enemy) do
   (do-stuff-with unit))

Cool.

I'm glad C# programmers get something like this. Why Microsoft didn't settle for filter/map/reduce methods, I'll probably never know. Haskell, ML, Common Lisp, Ruby, Python, Perl, JavaScript, Erlang, and probably a lot of others have had this sort of thing for a while, just under the admittedly somewhat intimidating name of higher-order functions.


That's kinda jQuery-looking to me.

Code: (javascript) [Select]
var enemyUnits = $(".battleUnits[type='enemy']").each(function(e,i){
    // ...
});


Granted, most of the jQuery I end up writing is still web-oriented but theoretically the library can be modified to work with more generic object models than the DOM, as previously shown with Prototype (Scrototype) and MooTools for Sphere.

Seems like y'all are starting to head towards a discussion of programming philosophy, which would probably be better suited to a separate topic unless it's directly related to Sphere Studio.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 04, 2013, 02:28:20 am

I see what it is, you're trying to manually search the "sounds" and "music" directories (the latter of which doesn't exist).  That's why I just had it search the whole project recursively, this way it picks up files whereever they happen to be.  The Sphere engine itself doesn't really care where you put stuff, so I figured the editor and plugins shouldn't either in most cases.


Luckily github has a history, so I can show you that it's not entirely my fault ( ;) ). You manually searched the sounds directory, I just added the 'music' directory. It so happens that the sounds directory was a standard sphere directory (one of the 7 created automatically) and so it's existence was (almost) guaranteed. See the history: here (https://github.com/Radnen/spherestudio/blob/3f60423e4eeb1f8d49c2a8c293884dc4b26edd23/SoundTestPlugin/SoundPicker.cs#L152). It's the last time you touched the repo, perhaps you had made an uncommitted change?

So, I guess we make it check the entire project. It beats relying on the existence of directories the user may or may not have.

Anyways, try to refrain from making code changes right now. I want to upgrade the whole project to .NET 4.0, and try to get VS2012 installed. So this might take awhile. I said I was busy, but seeing as this is now the weekend now I can take a little more time to do this.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 04, 2013, 02:44:14 am
That's odd, I know I originally had it explicitly search the sounds directory, but I could have sworn I changed that later in development... Oh well.  I think I must have had to revert my changes for some reason and then forgot to make the edit again.

But yeah, I'll leave the code as-is for now while you upgrade the project.  It'll give me a chance to do more work on Specs.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 04, 2013, 04:19:44 am
It is done. .NET 4.0 and VS2012 Premium are now being used.

With that I gotta rant.
I hate the look of VS2012! HATE IT!... And so I changed the default theme to the old 2010 editor style and now it looks slightly less garish. It's still ugly as hell, for one, they removed ALL visual cues. ALL OF THEM. I can't tell what a folder is apart from references and properties, and I can't tell menu items apart. Two-bit icons were definitely not the way to go here. There are also no icons on docked controls, for example the toolbox doesn't have the tool icon I look for. The menu bar doesn't start or stop anywhere, hell that applies to all the damn borders (my eyes just flow off the screen, I get disoriented). It's goddamn useless now. I don't care what people say or if they say "you'll get used to it", because that's plain rubbish. I never had to get used to VS2010, I fell in love with it the minute I put my eyes on it. That said, Github's Windows Git tool also looks in a similar way (borderless, crappy design) but is a far simpler tool and so I can manage that, but still I can't tell where the splitter bars are. What happened to the older, steadier designs of the past? This is plain ridiculous. Apparently, I'm also not the only one. A Google search returned hundreds of people saying the exact same things.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 04, 2013, 11:03:12 am
Yeah, the IDE is ugly as hell.  I get that they were going for an Office 2013 look, but Office did it better (I do like the Office 2013 look).  You will get used to it, though. Note I didn't say you'll ever LIKE it, just that you'll get used to it. Because it really is a nice IDE other than that--I love the new Start screen, for example.

I understand what they were going for, at least--minimize distractions so you can concentrate on the code instead of clicking around fiddling with other stuff (something I was guilty of with older versions of VS, more than I'd care to admit).  Which is an admirable goal for a programming environment.  The problem is that the total lack of contrast destroys all visual separation between things, so if you do have to look anywhere other than the code window, you get lost.  The idea was good, but the execution is all wrong.

Edit: Wow! The conversation was worth it, though: VS compiles the project much faster now, I wonder why .NET 2.0 took longer to compile... So um, am I allowed to fix bugs/implement features again? :)

Edit 2: Hm, looks like Microsoft was listening.  If you install SP2 (actually I think they call it "Update 2" now, but same thing), they added a "Blue" theme to the preferences that makes it look more like VS 2010.  The 2-bit icons are unchanged unfortunately, but at least there's a clear separation (a thick dark blue line, ala VS2010) between dock panes now.  Much more usable.  Unless that's the theme change you were talking about...?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 04, 2013, 02:50:55 pm
Yeah, I got the blue theme by downloading the VS theme plugin (http://visualstudiogallery.msdn.microsoft.com/366ad100-0003-4c9a-81a8-337d4e7ace05). You can also follow this tutorial here to get rid of the other crappy stuff: http://computerbeacon.net/blog/visualstudio2010iconsandt.

**Edit**:
When you make a new plugin, how do you get it to automatically move the DLL to the correct folder? It does it for all existing plugins, but not for any news ones. I'm right now in the process of actually creating a different script editor, using this (http://www.codeproject.com/Articles/161871/Fast-Colored-TextBox-for-syntax-highlighting).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Metallix on May 05, 2013, 08:45:35 am
Crazy... I don't want to start a fundamental discussion, but I want to add that I fell in love with the new VS2012 style. So much that I am currently using it to edit my multiplatform JS project. Its JS support became very good. Maybe it is only because I am also very happy with the whole metro look and feel. I just wanted to say that there are actually people who like this change ^^;

But yeah, forcing everyone to use a completely redesigned UI in VS is probably not the best move of Microsoft...
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 05, 2013, 10:35:36 am

When you make a new plugin, how do you get it to automatically move the DLL to the correct folder? It does it for all existing plugins, but not for any news ones. I'm right now in the process of actually creating a different script editor, using this (http://www.codeproject.com/Articles/161871/Fast-Colored-TextBox-for-syntax-highlighting).


Add the plugin as a project reference of the editor so it copies it to the output directory first. If it's not named ending in Plugin, you'll also have to modify the move command under Project Properties -> Build Events.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 05, 2013, 05:56:56 pm
Alright, I have added a new scripting plugin. Tell me what you think.

The plugin lacks autocomplete, but the new FastScriptEditor.DLL has a built-in way of handling it, which is nice. I can even get an intellisense-like autocomplete out of it too! Just gotta implement it.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 05, 2013, 09:24:33 pm
Well, the new plugin certainly looks nicer... but it also feels a lot more sluggish compared to the old Scintilla control.  I probably wouldn't have noticed it on my i7, but the all-in-one desktop in my living room only has a crappy AMD E2 dual-core processor (pretty much the AMD equivalent to a Celeron) and the new editor is noticeably laggy--enough to be distracting.  The Scintilla editor--and even Visual Studio's editor for that matter!--is smooth as butter on the same machine.

Edit: It also seems to be converting all the tabs in my JS files into spaces on load. Not nice.  Good thing I discovered that before I edited any Specs files, I would have had to go back and put all the tabs back... :)

Edit 2: The performance difference is even noticeable on the i7.  It's at least usable there (only barely noticeable when scrolling), but I should not be able to perceive scroll lag on a 3rd gen Core i7 (nope, not even if I'm specifically looking for it! ;) ).  Are they really sure this is a FastColoredTextBox? :D
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 06, 2013, 12:01:10 am
Wow, I hadn't noticed the speeds. Haha, well I guess I'll have to call him out on that. It's not fast. But, to be fair it did have a much better API than the scintilla one, and the fonts display much better, and the folding, and the line numbers, and bracket matching (it really solved a lot of problems in far less code). Plus, the Scintilla control is no longer being worked on. I want a nice text editor that behaves just like the .NET one.

The problem, just about the only one with the Scintilla editor, is the font. I have it on 'Consolas 10', but it looks... thinner, or lacks anti-aliasing. Do you also get that? It makes it look like twigs. It's also a fairly dated box, if it were not for it being fast I would love to replace it.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 06, 2013, 12:28:38 am
There's definitely a difference between the look of Consolas 10 in the Scintilla box versus the new one.  To be honest, though, I think I liked the thinner look better.  The FastScriptPlugin makes the text a bit more bold, almost identical to the way VS renders it, actually.  But now I feel like I'm going to get lost in a wall of code (and it's my own code, so that's saying something)... Maybe it's just that I have to get used to it, though.  It never bothered me in Visual Studio, no reason it should be any different just because it's JS instead of C#.

For what it's worth I say stick with the Scintilla editor as the default, at least for now, and provide the new one as an optional download.  If it were just lag when scrolling that wouldn't be a big deal, but I also noticed it when just entering text, there was a noticeable delay between when a character is typed and when it appears on-screen.  That would be quite distracting in day-to-day scripting, I'd wager.  But wow, I didn't realize the Scintilla control you were using was that old. Scintilla itself is still an active project, it was last updated (v3.3.1) only a month ago, but I just looked up Scintilla.NET and that's still only on version 2.5.2...

Edit: So what it looks like is that the Scintilla control is rendering the text with only standard anti-aliasing, whereas VS and the FastTextBox are rendered with full ClearType.  This is a great example of what a difference ClearType can make!
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 06, 2013, 01:10:10 am
Scintilla did use ClearType, the thinness had to do with the new way I'm using fonts. If I completely remove the font system from it, it will render the cleartype version of Consolas 10. But then it must pull from the XML always.

I guess I'll try going back to the drawing board on the font menu, perhaps go full-on with editing the XML via an editor, and then reloading that into the Scintilla control.

Also, the Scintilla control doesn't keep track of modified lines and the newer one does (I just have to enable it).

BTW, the FastScripter was only a trial. I never intended for it to replace the Scintilla box. However, one thing is revealed: removing a plugin doesn't dissociate it from the filetype list. When I switch between them, it will still load the other script editor, until I restart the editor. Huh.

Edit:
I have sorta gotten used to VS2012 now. :)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 06, 2013, 01:27:36 am
Haha, I did a trial run with the VS2012 blue theme, ended up going back to default gray one.  Too much color drew my eyes away from the code. :)  I guess that's the reason they went with those flat icons, too... yeah, it's harder to find stuff initially, but once you know where the necessary commands are, the lack of distractions is refreshing.

But that's odd with the fonts, so if you change the font in the Scintilla control programmatically, it renders the text differently than if the same font were used by default? Seems like weird behavior.  And yeah, I noticed that about the plugin registration.  I bet I know what it is: The plugin isn't actually being unloaded because the garbage collector still sees references to it--it still has the editor events hooked.  Let me try something...

Edit: Yep, that fixed it.  You have to unregister your event handlers in the Destroy() method, otherwise the previously-selected plugin still gets TryEditFile first, and once that's matched everybody else ignores it):
Code: (csharp) [Select]
host.TryEditFile -= host_TryEditFile;


I sent a pull request.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 06, 2013, 02:25:19 am
Well, that was a quick pull request, I had already figured that out and made those changes! I knew it had something to do with the events. I even removed the sound test's project events and TestGame event as well.

I got a good setup for the fold margin in the Scintilla control. And for now, I'll not force-style it anymore until I can solve this problem. I guess people will be forced to use Consolas 10 for a while. Hint: you can change sizes, etc. in the XML though. ;)

My next commit, you can see for yourself these scintilla changes.

Edit:
I still like the blue theme, I am not going to change that. :) My eyes can't even see the white theme, it really burns my corneas. Anyways, that's just an aside. Also, I like tabs too, but many do not, and Scintilla at least converts seamlessly between the two whereas the 'fast' control did not. So, I'm at odds with these script editors. Scintilla wins here, for now.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 06, 2013, 02:17:54 pm
Yeah, I'm fickle, currently I'm using 4-character tabs almost exclusively but I've been known to switch between 2, 4 and 8 depending on my mood.  A lot of developers like to use spaces for consistency (the code looks the same for everybody), but tabs are better for me because I change my coding style so much! :-)

The Scintilla editor looks much better now, by the way.  The only suggestion I have, and I don't even know if this is possible, is some sort of indication that a block of code is collapsed, you know, other than the plus box changing to a minus.  Visual Studio has that "[...]" indicator, and even the old Sphere editor put a vertical line under the fold...
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 06, 2013, 02:47:52 pm

The Scintilla editor looks much better now, by the way.  The only suggestion I have, and I don't even know if this is possible, is some sort of indication that a block of code is collapsed, you know, other than the plus box changing to a minus.  Visual Studio has that "[...]" indicator, and even the old Sphere editor put a vertical line under the fold...


Lord English, you do realize you're asking me to have a battle of wits with a crappy API. :P I don't know if it's possible, but there might be some folding properties in the lexer. I think it's possible to do a color change, but not a line underneath. And that is if I can figure it out! I mean, the margin fold lines I was just able to add I found out about by looking through old forum posts on the Scintilla.NET site. There's possibly more there too, hidden underneath a lot of noise.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 06, 2013, 02:53:26 pm
Doesn't the old Sphere 1.5 editor use Scintilla? Unless the Scintilla.NET API is drastically different, maybe you could take some hints from there.  I'd look into it myself but I'm not near a computer right now.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 06, 2013, 02:56:26 pm
So? The .NET wrapper's developers took upon themselves to change several aspects. Perhaps scintilla had a more open way of doing folding... .NET only exposes so much of it. There are 5 style methods, one reads 'custom'. I see no way, read no way of making a custom fold line. The API is not that good.

Edit:
Well I was able to get a line after the fold. :) Cryptic, but there. It's a property called Flags, and there are several flags you can choose from, such as fold lines. I did this by reading someones code repository on GitHub (since GitHub is far easier to peruse). Calling it flags though, still suggests the wrapper is not finished. There a more standard .NET way of doing this by using enums.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Flying Jester on May 06, 2013, 04:15:34 pm

It is done. .NET 4.0 and VS2012 Premium are now being used.


Wait, .NET 4.0 is being used for the editor? That may actually help cross-platform use. .NET 2.0 really doesn't like 64-bit Wine, but .NET > 3.0 is much happier there.


With that I gotta rant.
I hate the look of VS2012! HATE IT!... And so I changed the default theme to the old 2010 editor style and now it looks slightly less garish. It's still ugly as hell, for one, they removed ALL visual cues. ALL OF THEM. I can't tell what a folder is apart from references and properties, and I can't tell menu items apart. Two-bit icons were definitely not the way to go here. There are also no icons on docked controls, for example the toolbox doesn't have the tool icon I look for. The menu bar doesn't start or stop anywhere, hell that applies to all the damn borders (my eyes just flow off the screen, I get disoriented). It's goddamn useless now. I don't care what people say or if they say "you'll get used to it", because that's plain rubbish. I never had to get used to VS2010, I fell in love with it the minute I put my eyes on it. That said, Github's Windows Git tool also looks in a similar way (borderless, crappy design) but is a far simpler tool and so I can manage that, but still I can't tell where the splitter bars are. What happened to the older, steadier designs of the past? This is plain ridiculous. Apparently, I'm also not the only one. A Google search returned hundreds of people saying the exact same things.


There's a reason I use command line tools for a lot of my work. I also despise the graphical git for Windows. I tried for a very long time, and I still don't really know ho wit works. It needs more buttons, more borders, more...interface. I constantly close it, thinking that it will just close the working repo and put me back on the main screen.

'You'll get used to it', and 'you'll be as productive as you were before' is not a compelling argument for a redesign. If it's a good redesign, you should be noticeable more productive after getting used to it, not about the same as before (and have wasted all the time to learn it, as well).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 06, 2013, 08:26:36 pm
Yeah, Radnen just switched over to .NET 4.0.  It was originally using 2.0, but we both figured it was time to upgrade.  Win8 won't run .NET 2/3 apps out of the box anyway (needs a separate download), so we weren't saving anybody any time by sticking to the old framework version. :p
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: DaVince on May 07, 2013, 04:47:05 pm
After reading how you switched to .NET 4.0, I tried running this in Mono on Linux for the heck of it (seeing as I'm very interested in this becoming a cross-platform thing). It actually gets past the initial WinForms dependencies (once installed)! But it still errors out in a few ways:

Code: [Select]
Missing method System.Type::op_Equality(Type,Type) in assembly /usr/lib/mono/2.0/mscorlib.dll, referenced in assembly /usr/lib/mono/gac/UIAutomationProvider/3.0.0.0__31bf3856ad364e35/UIAutomationProvider.dll
Error setting up UIA: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Automation.Provider.AutomationInteropProvider ---> System.MissingMethodException: Method not found: 'System.Type.op_Equality'.
  at System.Windows.Automation.Provider.BridgeManager.GetAutomationBridges () [0x00000] in <filename unknown>:0
  at System.Windows.Automation.Provider.AutomationInteropProvider..cctor () [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at Mono.UIAutomation.Winforms.FormListener.Initialize () [0x00000] in <filename unknown>:0
  at Mono.UIAutomation.Winforms.Global.Initialize () [0x00000] in <filename unknown>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Application.InitializeUIAutomation () [0x00000] in <filename unknown>:0
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated.

Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.XplatUI ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Automation.Provider.AutomationInteropProvider ---> System.MissingMethodException: Method not found: 'System.Type.op_Equality'.
  at System.Windows.Automation.Provider.BridgeManager.GetAutomationBridges () [0x00000] in <filename unknown>:0
  at System.Windows.Automation.Provider.AutomationInteropProvider..cctor () [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at Mono.UIAutomation.Winforms.FormListener.Initialize () [0x00000] in <filename unknown>:0
  at Mono.UIAutomation.Winforms.Global.Initialize () [0x00000] in <filename unknown>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at System.Windows.Forms.Application.EnableVisualStyles () [0x00000] in <filename unknown>:0
  at Sphere_Editor.Program.Main () [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.XplatUI ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Automation.Provider.AutomationInteropProvider ---> System.MissingMethodException: Method not found: 'System.Type.op_Equality'.
  at System.Windows.Automation.Provider.BridgeManager.GetAutomationBridges () [0x00000] in <filename unknown>:0
  at System.Windows.Automation.Provider.AutomationInteropProvider..cctor () [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at Mono.UIAutomation.Winforms.FormListener.Initialize () [0x00000] in <filename unknown>:0
  at Mono.UIAutomation.Winforms.Global.Initialize () [0x00000] in <filename unknown>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at System.Windows.Forms.Application.EnableVisualStyles () [0x00000] in <filename unknown>:0
  at Sphere_Editor.Program.Main () [0x00000] in <filename unknown>:0
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 07, 2013, 08:59:48 pm
DaVince, was that the latest GitHub version ran through the Mono compiler? Or the 1.5.0 version here ran with Mono?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Flying Jester on May 07, 2013, 10:04:41 pm
I'll give it a try when my laptop and the internet meet up.

It can't be worse than before. I couldn't get .NET 2.0 to work in the first place with 64-bit Linux.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: DaVince on May 09, 2013, 08:28:28 pm

DaVince, was that the latest GitHub version ran through the Mono compiler? Or the 1.5.0 version here ran with Mono?

Just the 1.5.0 version here, ran with Mono. I'll try the latest Git tomorrow.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 12, 2013, 06:25:56 pm
What do you guys think about a solution manager in the Sphere Studio? The idea is that you can have multiple projects present in the project tree, each with the standard game directories (images, sprites, etc.) and then when you test a game it compiles into one directory: the one set up to be the project to load/run.

So, if you are like Alpha123, Lord English, or me and are developing a game alongside a (reusable) game library, this will be awesome to have.

What you do is set your game to the parent project, and then when you go test it, child projects are merged with your project. For example: RadLib's folders will be merged with Blockmans folders. Furthermore, it can be coded to only import the newer/changed versions of files. Overwrites may have to be handled with care.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: alpha123 on May 13, 2013, 12:45:02 pm
That would be extremely helpful. Might it be possible for a plugin to do some extra steps when things are copied over? e.g. compile CoffeeScript to JavaScript, or in my case compile JS to JS instrumented with some debugging information (I'm experimenting with a Sphere JS debugger).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 13, 2013, 01:27:28 pm

That would be extremely helpful. Might it be possible for a plugin to do some extra steps when things are copied over? e.g. compile CoffeeScript to JavaScript, or in my case compile JS to JS instrumented with some debugging information (I'm experimenting with a Sphere JS debugger).


We'll see when I get that far. It's going to take some work to implement. But I think that's doable.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Harry Bo21 on May 29, 2013, 12:25:03 pm
Just a quick suggestion

I always end up accidentally closing the editor when my game aborts (when i wasnt expecting it)

can you make it so that any branches that you closed in your scripts STAY closed?

Everytime i reopen the editor and open a script all the branches are open again and i have to go around closing them for easier navigation

10 mins later i do it again...

Talking about the original editor by the way, id love to see this feature in your as is driving me crazy (Damn my automatic ALT F4 reaction)

That or rather than the engine closing after any key, make it REQUIRE escape key?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on May 29, 2013, 04:37:29 pm
Remembering a text file's code folding state (as an option toggle, however) = a really good idea! How hard is it to implement in a Scintilla-based editor, Radnen?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 29, 2013, 05:27:30 pm
Give how much Radnen hates the Scintilla.NET control, probably quite difficult. :(. It is a good idea though, even if I never use folding personally (I prefer to see all my code at all times, and if there's too much to sift through then I know it's time to refactor).  I think Visual Studio remembers folding state (even across sessions), but only as long as you don't close the tab.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 29, 2013, 06:19:11 pm

Give how much Radnen hates the Scintilla.NET control, probably quite difficult. :(.


Well, that's because it's not very well documented!! Now, is there a way to do that? Quite possibly! But how easy is it to get to? We shall see... it involves looking through the API, the original API, source code, and SciNET forum posts. So It'll take some time. And where do I store that info? Where does Visual Studio store that?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on May 29, 2013, 06:40:08 pm
And where do I store that info? Where does Visual Studio store that?


Probably the user's data directory (ie, %AppData%\Local\%COMPANY_NAME%\%APP_NAME%). Check byuu's nall to see a surprisingly easy way to access the user's data directory that's also cross-platform (look for the userpath() function).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 29, 2013, 08:37:10 pm
@Radnen: I believe VS stores the folding info in the project's .user file, along with the list of open tabs and such (which is why you don't put the .user files in version control, devs on the same project would annoy the hell out of each other :) ).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 29, 2013, 09:03:21 pm
Hmm, so I'd just have to do something similar then. Create a .user file for my editor. Save tasks, open tabs, folds, etc. Alright.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Harry Bo21 on May 29, 2013, 09:30:45 pm
Quote
Hmm, so I'd just have to do something similar then. Create a .user file for my editor. Save tasks, open tabs, folds, etc. Alright.


Looking forward to it!

I tried this back on the old forums on one of your first builds, but after that ill admit i never tried the others.

But now I have and I love the modern look and feel. Good job Radnen!

My FF6 SDK looks much more organised and I REALLY like having the project pane hidden so it pops out when the cursor is over it! Really helps


BTW works on win8 out the box
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 29, 2013, 09:35:18 pm
Just took a quick look through the Scintilla control's methods (Intellisense is awesome, I don't care what anyone says), looks like you'll have to use the Scintilla.NativeInterface.GetFoldX/SetFoldX methods to implement this.   There don't appear to be any automated methods to do the serialization for you, unfortunately.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on May 29, 2013, 10:02:31 pm
@Lord English: that was also a fear of mine. Oh well, I think that's doable.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on May 30, 2013, 05:20:53 pm
Re serialization - use JSON for it? Easy to implement and json.org has links to a bunch of C, C++, and C# JSON parsers.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on May 31, 2013, 10:07:56 am
The problem here isn't the technology to use for the serialization, it's the method used to get the info to serialize in the first place.  Scintilla.NET doesn't make it easy to get at the relevant info for what we want to implement (saving code folding info).
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on June 09, 2013, 08:45:17 pm
@Radnen: Weird focus bug, I've been trying to hunt this one dow for days but can't seem to figure out what's causing it: Either it doesn't respond to keyboard shortcuts/menu items at all, or they're handled by the wrong tab. Very bad when I end up pasting text into a script I'm not actively working on and don't realize it right away...  Unfortunately, I can't reproduce it on command (it seems to be quite random), but it's common enough to be frustrating.  There are times when it won't even respond to any hotkeys at all and I have to restart the editor to fix it.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on June 09, 2013, 10:57:32 pm
I notice that too! I've also been searching for a solution. The work-around is currently by opening the menu by hand and clicking on the function you want. After that it'll recognize key inputs.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on July 04, 2013, 03:33:24 pm
Hey, so I cleared out my plugins and went to reload them and I can't open up your sound test plugin. The error is so fatal not even the windows debugger can help me. :(

I don't know what's going on exactly.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 04, 2013, 03:42:16 pm
How would I reproduce it? If I can see what's happening I may be able to diagnose it on my end...
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on July 04, 2013, 03:51:09 pm
Did you try turning off all plugins and then turning them back on?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 04, 2013, 04:09:20 pm
You mean in the same session? I can't test it right this second as I'm at work, but I'll look into it later.  Probably has to do with double-init of Irrklang or something like that...
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 04, 2013, 07:43:24 pm
I can't reproduce it... well, not entirely.  Clearing all plugins and then re-enabling them works fine, including Sound Test, although I did notice that the editor hangs for a couple seconds at a time when enabling or disabling it.  This happens in both release mode and under the debugger.  The plugin doesn't really do anything radical, so I'm going to guess the issue is with IrrKlang.

Unfortunately I can't really do much else as far as diagnosing the problem until later.  I'm at my grandmother's house using a laptop with none of my files on it, the only reason I was able to compile the editor at all was by using the portable copy of SharpDevelop on my flash drive, and as you can probably imagine, compiling code on a flash drive is painfully slow.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on July 04, 2013, 08:18:08 pm
I get an error page that looks like this. It must've been your latest update that caused it. When I run the program again, I can enable and disable the sound plugin, but nothing happens.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 04, 2013, 08:25:49 pm
Yeah, I didn't get any such message, and that's with the most recent files from your repo...if you click the "what settings are applied?" link, what does the Help info say?

Also, which build? x86 or x64?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on July 04, 2013, 08:38:12 pm
What settings were applied takes you to a shitty MS help page on what the compatibility assistant is.

I'm running it in x64.

Edit:
"A first chance exception of type 'System.IO.FileNotFoundException' occurred in SoundTestPlugin.dll"
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 04, 2013, 08:47:46 pm
In my experience, the Irrklang DLL you have in the the repo only works on x86, if I compile for x64 I get a platform mismatch error as soon as it tries to load the DLL (I.e. upon loading the SoundTestPlugin).

Edit: File not found... That's interesting.  Any way you could expand the exception and see what the file it was looking for is?
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on July 04, 2013, 09:06:50 pm
Hmm, you are right about that. I thought I had it working in x64, but I guess not.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 05, 2013, 12:19:43 am
Yep, just compiled to x64, got a bunch of compile warnings about architecture mismatches, and sure enough, a FileNotFoundException citing the IrrKlang DLL when trying to enable the SoundTest plugin.  Compile for x86, everything goes off without a hitch (save for the momentary lockup mentioned earlier).  I wonder if there are any 64-bit binaries available for IrrKlang...

Edit: Nope, doesn't look like it, irrKlang is 32-bit-only according to their site, even under Linux.  Looks like we might have to look for another audio library if we want to have x64 support.  Might want to let Jester know too, since I think he's using irrKlang for TurboSphere...
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on July 05, 2013, 01:34:18 am
Well IrrKlang was supposed to be 64 bit by now. Now I need to search for a good sound library that is also subsequently free to use. Bass.net looks good. But ugh, it's license came straight out of hell.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 05, 2013, 01:47:05 am
What about FMOD?  It was awesome when I used it years ago, don't know how OSS-friendly it's license is though.  BASS might be better though, foobar's MIDI plugin uses that and it lets you use SF2 sound fonts, which is awesome.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Flying Jester on July 05, 2013, 07:23:50 pm
Bass is really cool, and that's what I use for TurboSphere. That would also let TurboSphere and Sphere Studio share a library. Bass's plugin system is really slick, but I have to say it doesn't work absolutely flawlessly on Linux (plugins can't seem to overload the stream opening functions, although that's not vital).

I do agree, the license is a little annoying, but it doesn't look terribly different from the irrKlang license to me.

Also, the lack of 64-bits is why I didn't use irrKlang for TurboSphere. I'm quite done with 32-bits, and now I'm just waiting for the rest of the world to be as well so I can finally just distribute win64 binaries.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 05, 2013, 07:29:56 pm

Also, that's why I didn't use irrKlang for TurboSphere. I'm quite done with 32-bits, I only compile TS for Win32 because I know I can count on most people who can't or won't compile it themselves being able to run win32 programs.

Actually, unless you need to full capability of 64-bit (i.e. access to more than 4 GB of RAM, unlikely a 2D engine like TS would ever need that much), the general recommendation has always been to build for 32-bit anyway.  It won't be any slower (32-bit isn't emulated like 16-bit is, you're using real Win32 binaries), and compatibility is better.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: alpha123 on July 05, 2013, 07:32:30 pm

Actually, unless you need to full capability of 64-bit (i.e. access to more than 4 GB of RAM, unlikely a 2D engine like TS would ever need that much), the general recommendation has always been to build for 32-bit anyway.  It won't be any slower (32-bit isn't emulated like 16-bit is, you're using real Win32 binaries), and compatibility is better.

Well, it can be a little faster because 64-bit programs have access to twice as many registers, right? Although 64-bit pointers use twice as much memory, so it's a trade-off.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Flying Jester on July 05, 2013, 07:46:42 pm
Yes. Twice as many general purpose registers, loading into vector registers from general purpose registers takes fewer cycles, and probably some other things I'm unaware of. Nothing super awesome, but every bit helps.

I try as hard as I can on my Arch machine to use 64-bits only (and have succeeded so far). I want to use the best software (in whatever family of OS I am using at the time, I apply this to Windows, too) for the machine that I can. If I have a 64-bit machine, I should try and use a 64-bit OS and 64-bit software.

And using V8, you only have 2 GB for script in 32-bits, but you have 4 GB of memory for scripts in 64-bits.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on July 06, 2013, 01:38:58 pm
My recommendations:

1.   Consistency; whatever people hear in the engine should be what people hear in the editor. This desire may be nullified by using a tracker like Modplug over something closer to the final audio like Schism when making modules, however.
2.   As unlimited as possible; Sphere is still a GPL open-source engine with the ability to allow commercial projects. The dev group (ie, those working on the various versions of the engine and editors) needs as few limitations as possible in the vanilla distribution to allow end users to choose free or commercial status with a minimal amount of fuss.

That being said, this is a discussion that's been had a few times previously (Jester and Radnen were also involved in the discussion, among others) and the final decision was to use software that has a free license but also have the end user have to pay to use the relevant commercial license of included software should they choose to release a project commercially. Unity3D does this, as well as Unreal Engine (has student & indie licenses) and older versions of idTech; I don't know if CryEngine does this, however.

In this respect, I will be fine with choosing either irrKlang or BASS, but make sure it's used by all relevant Sphere programs; add FMOD to that list of choices if they've actually updated their capabilities to include formats previously covered by Audiere.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: DaVince on July 12, 2013, 04:14:33 pm
Question!

How's development? Especially interested in knowing if there's any cross-platform development in this, considering what I always develop on. :)
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 12, 2013, 04:22:19 pm
I seem to be the official bug-fixer and I haven't found any bugs in the past week or so, so I guess that's a good sign. :)  I'd say it's ready for another release, but that's ultimately up to Radnen...
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: DaVince on July 12, 2013, 05:39:20 pm
Okay, that's good to hear!

I wouldn't mind helping Radnen get this to work on Linux... through testing, not really coding. :P
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on July 12, 2013, 08:17:27 pm
What about in the browser with JSIL? lol.

I could release another version, it was part way through plugin creation.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Fat Cerberus on July 12, 2013, 10:18:45 pm
Haha, I was originally going to try to convert the map editor to a plugin myself, but then I got lazy. :P
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: N E O on July 19, 2013, 09:27:49 pm
Got an appcrash when trying to quit the app:

Quote

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
   at System.Collections.ArrayList.ArrayListEnumeratorSimple.MoveNext()
   at System.Windows.Forms.Application.ExitInternal()
   at System.Windows.Forms.Application.Exit(CancelEventArgs e)
   at Sphere_Editor.EditorForm.ExitMenuItem_Click(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5472 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
Sphere Editor
    Assembly Version: 1.1.5.0
    Win32 Version: 1.1.5.0
    CodeBase: file:///C:/apps/games/SphereStudio/Sphere%20Editor.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5468 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Sphere.Plugins
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/apps/games/SphereStudio/Sphere.Plugins.DLL
----------------------------------------
WeifenLuo.WinFormsUI.Docking
    Assembly Version: 2.7.0.0
    Win32 Version: 2.7.0.0
    CodeBase: file:///C:/apps/games/SphereStudio/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
TaskPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/apps/games/SphereStudio/Plugins/TaskPlugin.dll
----------------------------------------
Sphere.Core
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/apps/games/SphereStudio/Sphere.Core.DLL
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.


The open file at the time was aldat.rts from a super-old Blockman demo so I could compare the web utilities output to it in the editor.
Title: Re: Radnen's Sphere Studio v1.1.5.0
Post by: Radnen on July 19, 2013, 09:31:51 pm
Hmmm... That migh've been fixed between then and now. I'll see about getting another editor release put up. Edit: I've put up the version Lord English and I had been working on.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Xenso on July 31, 2013, 07:08:44 am
Where can I install the latest version of .NET framework?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on July 31, 2013, 09:08:03 am
.NET 4.5 download:
http://www.microsoft.com/en-us/download/details.aspx?id=30653
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: N E O on July 31, 2013, 04:13:11 pm
How about a 64-bit build of 1.1.6.0?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on July 31, 2013, 05:20:10 pm

How about a 64-bit build of 1.1.6.0?


I could; but you won't have an audio plugin.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Xenso on July 31, 2013, 05:38:07 pm
Still wont work on my computer after installing .NET

It just says it "stopped working" then gives me these details

Quote

Problem signature:
  Problem Event Name:   CLR20r3
  Problem Signature 01:   sphere editor.exe
  Problem Signature 02:   1.1.6.0
  Problem Signature 03:   51e9ea2f
  Problem Signature 04:   mscorlib
  Problem Signature 05:   4.0.30319.17929
  Problem Signature 06:   4ffa561c
  Problem Signature 07:   26a0
  Problem Signature 08:   0
  Problem Signature 09:   System.IO.FileLoadException
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:   1033
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on July 31, 2013, 05:42:57 pm
What are you doing with it? All you are doing is opening it, right? Or are you opening a particular file?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Xenso on August 01, 2013, 04:49:22 am
I'm just opening Sphere Studio itself not a file
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 01, 2013, 06:16:08 am
Is it a clean install?

Things that changed:
1. Saved layouts.
2. Task lists.
3. Editor ini
4. Sphere lexer.

I guess my editor could use better error reporting here but that might be a start to your problem - which I've never encountered. Maybe it was a packaging issue? Tomorrow I'll investigate further.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Xenso on August 02, 2013, 04:32:47 am
I think its clean, I downloaded it as a zip file so technically I never installed anything.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 02, 2013, 06:01:54 am

I think its clean, I downloaded it as a zip file so technically I never installed anything.


But your game may be using an older version of a task list. Check to see if you have one in the project you are editing.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Xenso on August 02, 2013, 08:38:14 am
ok where do I check?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 02, 2013, 01:15:04 pm
Radnen, do you mind if I go ahead with converting the rest of the built-in editors to plugins?  I don't want to have to deal with a merge conflict if you're already in the process if doing so.  Oh, that reminds me, it looks like you didn't make a commit for 1.1.6.0...
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 02, 2013, 02:32:14 pm

Radnen, do you mind if I go ahead with converting the rest of the built-in editors to plugins?  I don't want to have to deal with a merge conflict if you're already in the process if doing so.  Oh, that reminds me, it looks like you didn't make a commit for 1.1.6.0...


Yeah, you can go ahead now. The latest commit was just a simple version number change to identify the most recent build.


ok where do I check?
It's a file I (creatively) called tasks.list, if you do not have one in your project then it doesn't matter. I just tested the sphere editor out of the box, it works perfectly. Did you set correct paths for the engine and editor? Did you try running it as a Windows admin (right-click and choose "run as administrator")?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 02, 2013, 07:27:31 pm
Wow, apparently I had no idea what I was getting myself into. :P  The map editor has so many sub-components... this is going to take a while.  The main issue is changing all the namespace references; I can't use Visual Studio's built-in identifier renaming for this unfortunately.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 02, 2013, 07:30:02 pm

Wow, apparently I had no idea what I was getting myself into. :P  The map editor has so many sub-components... this is going to take a while.  The main issue is changing all the namespace references; I can't use Visual Studio's built-in identifier renaming for this unfortunately.


Yeah it was pretty heavily integrated, also the script portion would be the hardest; do you use a plugin or do you keep it separate?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 02, 2013, 07:34:57 pm
I like the idea of using a plugin, but that requires an additional feature for a plugin to specifically register itself as, like, a default script editor or something?  I think I'll just keep the internal script editor there for the time being.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 02, 2013, 08:18:08 pm
Since you're looking into the map code, what do you think of the editor's map blitting code? Isn't it rather neat, Google maps inspired me. :)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 02, 2013, 10:12:37 pm
I didn't look too much at the code yet, but I'll be sure to check it out now. :)

edit: Holy shit, this thing is a monstrosity. Which class handles map blitting, exactly? :P  I think I'm almost done with the conversion... still won't compile, need to move all the resources over for the toolbar icons and stuff.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 03, 2013, 11:54:56 am
@Radnen:
Almost done, there's just a few snags preventing me from finishing the conversion: Global.IsScript() and Global.CopiedEnt. Neither of these seem to be available from plugin code and it looks like MapControl depends on them.  What should I do?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 03, 2013, 03:28:11 pm
The two globals can be stuffed into the map plugin, I don't know where IsScript would be used but CopiedEnt is really only used by the map editor, make it a private static field.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 03, 2013, 10:27:58 pm
Yay, the map plugin works!  I feel like it's a bit bloated though, some of the stuff could go into Sphere.Core I think (the Drawer2 being the main candidate)... but that's the biggest one out of the way, now I have the spriteset and windowstyle editors to do.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 03, 2013, 11:18:44 pm

Yay, the map plugin works!  I feel like it's a bit bloated though, some of the stuff could go into Sphere.Core I think (the Drawer2 being the main candidate)... but that's the biggest one out of the way, now I have the spriteset and windowstyle editors to do.


Woah, yeah, umm that would go right into an image plugin. So... I think it's wise to have the ability to set default sound / image / etc. plugins.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 04, 2013, 12:34:17 am
Yeah, I decided to hold off on further plugin conversion until some updates are made to the plugin system.  Otherwise we'll end up with 5 separate copies of core components.

edit: I opened a pull request on GitHub, this way you can test the map plugin too.  I haven't gotten to the map-making stage in Spectacles yet, so I won't get much mileage out of it.  You'd be able to test it more thoroughly, I think.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: williammah on August 04, 2013, 02:54:18 am
Chrome wouldn't let me download the editor; says it's malicious or something like that. Had to choice but no discard it D:
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 04, 2013, 03:31:30 am

Chrome wouldn't let me download the editor; says it's malicious or something like that. Had to choice but no discard it D:


It's fine. I can guarantee that! :) Chrome says that to any software that doesn't pay a million dollar license, small homebrew apps like this always get the short end of the stick sometimes.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 04, 2013, 11:23:02 am
@Radnen:
Just added an image editor plugin.  Now I just need to come up with a way to get other plugins to be able to call into the image plugin and I'll be able to do the spriteset and windowstyle editors. :)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 09, 2013, 09:53:00 pm
Well, just got done with a massive overhaul of the codebase, moving the rest of the editing code out into dedicated plugins in the process.  Sphere Studio is now fully plugin-based. :D  Now I'm just waiting for Radnen to merge the modifications, and we're good!
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 12, 2013, 07:29:23 pm
Good lord, I just went to switch the sound plugin over to BASS instead of irrklang, and the .NET API for BASS is atrocious.  Seriously, you have no idea.  They literally just made a big static class and dumped the entire C API into it verbatim.  No objects or anything, and all the handles are ints (not even IntPtrs!)  So for now I think I'm going to hold off on that. :P
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 13, 2013, 08:35:43 pm
Great changes Lord English!

I'm going in now to do some styling updates. I want to try out a different color theme... What do you think of carbon-fiber black?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 13, 2013, 10:19:37 pm
I don't know, I feel the current blue theme is a nice neutral color for development (hence why VS uses a similar shade), the black look might prove to be overly distracting. I'd really have to see it in action to give a proper opinion, though...
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 13, 2013, 11:50:23 pm
LordEnglish, you can take a look if you want now.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 14, 2013, 12:12:00 am
Hm, not bad.  I noticed you increased the font size in the dialog forms, might want to increase the default script font size from 10 to 11 though (via SphereLexer.xml), if that's what you're going for.  10-point Consolas is rather tiny at 1080p and up, and gets pretty straining during long coding sessions.  As for the dark look itself, it's a lot better than I was expecting.  A darker scheme does make sense for a game IDE, you want a bit more contrast than general-purpose development.  Is there any way to also change the color scheme on the dock panels to match?

My only complaint is the new main icon, it has no contrast.  The hammer should stand out a bit more from the background, I think.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 14, 2013, 01:46:16 am

My only complaint is the new main icon, it has no contrast.  The hammer should stand out a bit more from the background, I think.


I might get my brother to make a new icon. Or I can try another retooling with a larger hammer icon.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 14, 2013, 02:07:22 am
Larger hammer would help, but it still needs more contrast.  The hammer is too dark and gets lost in the circle, especially with the brightness turned down (I try to keep my laptop in Eco mode to save battery).
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 14, 2013, 04:31:56 am
Okay, I went back to the orange icon and updated it. I like the new bold look, I think that version just has a more standout quality than the black version.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 14, 2013, 10:38:15 am
Yeah, wow, this icon looks much, much better.  Looks more modern :)

One thing, though: You should add a 256x256 icon to be fully up to current Windows (that is, Vista and later) specs.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 14, 2013, 01:05:14 pm

One thing, though: You should add a 256x256 icon to be fully up to current Windows (that is, Vista and later) specs.


I can't, I'm using an online icon tool, and it only goes up to 64*64 sized icons: http://www.xiconeditor.com/

For a filetype often used by Windows I haven't found a good icon editor. There are so many crappy ones out there and I don't trust them.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 14, 2013, 02:28:44 pm
IcoFX is really good, it's commercial but I'm pretty sure they have a free version.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: N E O on August 14, 2013, 02:59:39 pm
I've been using free IcoFX Portable (should be on PortableApps) for a super long time. It's how I compiled the Spherical logo to icon format.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 18, 2013, 01:18:29 am
I just added a style prototype to the latest version on the repository. Basically you can use 1 of 5 built-in styles (color scheme with font and image choices) or make your own and throw it into a plugin. It's fairly bare-bones right now, but I'm aiming to expand on it. Already the styling looks pretty good despite the limited number of styling options.

I'll also use graphics to create more exotic styles and give the option to style specific controls and not just general controls (which can look odd at places).
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 18, 2013, 11:14:27 pm
This is nice, Radnen!  The black theme with Tahoma as the font really makes it look like a game-making tool now.

So what is the API for doing this with a plugin? Or didn't you implement that yet?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 19, 2013, 12:31:29 am
The API for plugins is simple:

Code: (csharp) [Select]

var my_style_group = new StyleGroup();

my_style_group.Label = new Style();
// ...

StyleSettings.addStyle("CoolTheme", my_style_group);

// ...

StyleSettings.removeStyle("CoolTheme");


BTW I just expanded the style options (latest github code), now status bars, toolbars, and menu bars are styleable. The style system I use is not automatic, all controls need to be manually told what things get styled. I don't think that's bad considering the plugin author / I can choose what gets styled and what does not to prevent some weird style artifacts from happening: such as the awkward black text on black background.

There is still one issue: the settings editor does not enumerate a list of all styles. So far it just enumerates the built-in styles. But that will change shortly (it's not like we suddenly get a new style plugin tomorrow, lol).
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 20, 2013, 10:59:52 am
Just tried out the updated version, looks really nice with the toolbars and menus styled as well.  If I had to say one thing though, it's that the green theme is a bit too bright.  Might want to go for a darker shade, closer to the green in my avatar.  Bright lime green is a bit distracting.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: N E O on August 20, 2013, 03:23:31 pm
How about a 64-bit build? ;)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 20, 2013, 04:00:09 pm
Soon, there are changes that I want to finalize before I make an official v1.7. But you can use the 32 bit build in the meantime. The irrklang audio player plugin won't be available in the 64 bit build, however.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 20, 2013, 05:12:05 pm

How about a 64-bit build? ;)


I honestly don't see what 64-bit gains us at this stage of development.  Nothing in it uses ludicrous amounts of memory (seriously, if I start seeing 2+ GB maps I'm running for the hills) and it's an IDE so there are no CPU-intensive tasks it does that would benefit from the extra registers/expanded instruction set.  A 64-bit engine makes sense, but it just seems like overkill for an editor.  Maybe that's just me, though.

Edit: 64-bit is also harder to debug.  VS essentially has to start a remote debugging session since the CPU is so locked down in long mode that you can't debug natively (this is why Sharpdevelop won't debug x64 apps). Not only does that take longer to start up a debugging session, but you lose some debugger features as well I think...
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 20, 2013, 05:16:22 pm
Lord English: I agree with your sentiments; that's precisely the reason why you don't see a 64 bit build of IrrKlang. In this day there is still little reason to go 64 bit, it was only pushed to the consumer market as a business strategy since "32 bits" was basically sounding too old. :P

But I mean, I can make such a build, even if it doesn't make a lot of sense it's really just a button click away.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 20, 2013, 05:18:25 pm
@Radnen: I just made an edit to my post re:debugging that you might want to know.  It didn't warn me when I made the edit that you ninja'd me...
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on August 20, 2013, 08:12:36 pm


How about a 64-bit build? ;)


I honestly don't see what 64-bit gains us at this stage of development.  Nothing in it uses ludicrous amounts of memory (seriously, if I start seeing 2+ GB maps I'm running for the hills) and it's an IDE so there are no CPU-intensive tasks it does that would benefit from the extra registers/expanded instruction set.  A 64-bit engine makes sense, but it just seems like overkill for an editor.  Maybe that's just me, though.


In this day there is still little reason to go 64 bit, it was only pushed to the consumer market as a business strategy since "32 bits" was basically sounding too old. :P

But I mean, I can make such a build, even if it doesn't make a lot of sense it's really just a button click away.


I for one would like to see a 64-bit build. I have a 64-bit machine with a 64-bit OS, I much prefer to use 64-bit software whenever possible.

For Mono, there is a good reason to offer 64-bit as well. I wouldn't have to install all the 32-bit Mono stuff along side the 64-bit version.

That doesn't stop me or discourage me from using a 32-bit version if that's all there is, mind you.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 20, 2013, 08:53:29 pm
If a given app doesn't do anything that warrants full 64-bit support, you're just adding bloat (larger pointers, etc.) by compiling it to x64.  Of course, this argument is only for applications.  For middleware like irrklang, there's no excuse in my eyes for not providing a 64-bit build, since you can't link a 64-bit app (which may indeed have a good reason for being so) against a 32-bit DLL.

It also might be worth mentioning that, as far as I know, MS still recommends everyday end-users install the 32-bit version of Office, even on 64-bit machines.

That said, there will be a 64-bit build of Sphere Studio eventually, we just have to find a different audio engine than IrrKlang.  As mentioned earlier in the thread, I tried BASS, but the .NET wrapper for it is horrible--it's literally a verbatim transcription of the C API.  I really don't have the patience to deal with that at the moment.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 21, 2013, 12:46:18 am
Hey Radnen, I noticed a glitch where, on startup, the panes on the start page are misaligned.  I've tried several things to fix it (Refresh, PerformLayout, etc. and at several levels of the docking hierarchy), but to no avail.  I initially suspected a bug in DockPanelSuite, but then I realized it's only the start page that's messed up, the rest of the UI seems fine.  Any idea what's causing it?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 21, 2013, 01:31:21 am
I have seen that too. I have the faintest idea of what's happening. It never used to do that prior to the move to .net 4.0. I do notice that if you jiggle the divider between the start page and the project file list, it will realign. So it has to be a docking issue. Also, hiding it and showing it will realign the panel. I think a quick n' dirty workaround is to show/hide it.

Edit: I fixed it.
What did the trick was to rearrange the order in which the panels popped into view. Which is a strange but it seems to work.

Also, sometimes the style colors did not update for the panels in the start page (still hold the old color until you did the two things above). The labels did update fine, however. But after this fix it all seems to work properly now.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 21, 2013, 11:00:47 am
@Radnen: I just implemented custom style selection in prefs; check your pull requests on GitHub. :)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 21, 2013, 05:44:47 pm
Love the new style changes, Lord English. I just pushed some other changes too. I now added 'secondary' styling. It's basically a catch-all styler for nested components. The useful thing here is that foreground, nested controls can stand out with a custom backing. The next step is to go through each plugin and have them implement the IStyleable interface - which basically says "this control has been given the ability to style itself", even though there is technically no manager that does it. I just think it's cleaner from a code point of view to have standardized a single method into an interface for styling - kinda like how IDisposable works for disposing.

Anyways, some neat themes are coming along. Oh, I also tweaked the colors so they look softer/more natural. I even gave the light theme a light secondary color for labels since an all-white theme was a bit too overwhelming (thanks MS for creating such a crappy theme for VS2012 :P), I hope the slight change makes it easier on the eyes.

Tell me what you think of this 'secondary styling option'.

Also, I modified the editor settings to use a more styled presets menu, then I added an Apply button so you can 'try before you buy' kind of thing. But you actually end up buying since it works like all apply buttons do and saves all the others changes right there and then without leaving the dialog box.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 21, 2013, 07:17:08 pm
Hm, not sure I like the list backgrounds being muted like that, especially since almost every other app uses white for the back of lists (a dull background is usually an instinctive visual cue that the control is disabled).  We can make custom themes later that use a different back color for the lists, but the built-in ones should stick to white, I think.  As for the secondary style, it seems like a good idea, but I'm not entirely sure I understand its purpose... is it like, if no style is defined for a given control type, you apply the secondary style?

Oh, and the Apply button is in an awkward position.  Almost every Windows app I've ever used puts the buttons in this order: OK, Cancel, Apply.

And regarding VS2012: They added more color to the icons in VS2013 (folders are back to being manilla, and the toolbar icons are more colorful and stand out more), and the VS2010-style "Blue" theme seems to be the default now.  I guess they learned from their mistake. :)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 21, 2013, 07:53:37 pm

Hm, not sure I like the list backgrounds being muted like that, especially since almost every other app uses white for the back of lists (a dull background is usually an instinctive visual cue that the control is disabled).


But the trick here is that people know this is themed; plus the disabled style is bad taste on MS for locking it down like that: they should have given people the ability to style that coloring as well. Look at Photoshop, it's all kinds of colors but it doesn't use .NET controls. I'll not style the list view then. But you are right I don't want the built-in styles to be too exotic.

Quote

We can make custom themes later that use a different back color for the lists, but the built-in ones should stick to white, I think.  As for the secondary style, it seems like a good idea, but I'm not entirely sure I understand its purpose.


The purpose of the secondary style is to highlight nested controls. Without it everything else would be white. Look, I can style all panels, but what happens if I want a panel to be of a secondary color? It couldn't happen, secondary is intended for styling the other control, and as I said is usually a nested control.

Quote

Oh, and the Apply button is in an awkward position.  Almost every Windows app I've ever used puts the buttons in this order: OK, Cancel, Apply.


I actually was thinking it to move to the far left. But ok, I guess to the right is alright. That said I am going to change OK to "Save" as because that sounds more informative.

Quote

And regarding VS2012: They added more color to the icons in VS2013 (folders are back to being manilla, and the toolbar icons are more colorful and stand out more), and the VS2010-style "Blue" theme seems to be the default now.  I guess they learned from their mistake. :)


I'm really happy to hear that. :)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 21, 2013, 08:21:57 pm
Haha, you'll find that I can be like the GUI police at times, I'm a big proponent of consistency in that area.  Things like button order and such tend to be standard across the board, so when the odd app does it differently it can be disorienting.  Like, originally, you had the buttons in order Cancel-OK and I was forever cancelling out when I really wanted to save the changes, so I finally swapped them around when I overhauled it.  This was always my biggest complaint with Linux: Every program tends to have its UI set up a little differently, so it's a learning curve every time you want to try a new one.  Whereas things tend to be more standardized on Windows.

But yeah, that makes sense with the secondary styles now.  If you have a nested panel you apply the secondary style to it instead of the primary to get some contrast.  Indeed a good idea. :)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 21, 2013, 10:27:28 pm
On the topic of standardized windows, there really isn't a standard per se, but there are some you can subscribe to such as this one from some company named SSW: http://www.ssw.com.au/ssw/Standards/rules/rulestobetterwindowsforms.aspx

I'm sure there are more examples out there.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 21, 2013, 10:39:46 pm
I didn't mean a formal standard though, I realize one doesn't exist (I assume MS has some kind of UI standards for Windows Logo certification though), I basically just meant most developers try to mimic the way the OS's built-in programs do it when possible.  On Linux that doesn't seem to happen, every app kind of does its own thing and you lose the sense of... I guess unity would be a good word?  Of course the sheer proliferation of disparate Linux distros probably doesn't help in that department.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: DaVince on August 22, 2013, 04:57:29 am

I didn't mean a formal standard though, I realize one doesn't exist (I assume MS has some kind of UI standards for Windows Logo certification though), I basically just meant most developers try to mimic the way the OS's built-in programs do it when possible.  On Linux that doesn't seem to happen, every app kind of does its own thing and you lose the sense of... I guess unity would be a good word?  Of course the sheer proliferation of disparate Linux distros probably doesn't help in that department.

Unless a person makes a Gtk-based app and follows their big book of user interface guidelines. KDE might also have a similar set of GUI standards, but I'm not sure.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on August 22, 2013, 07:43:58 pm
KDE does have standards for UI design. So does LXDE. Many programs follow the standards (or at least try to) of whatever environment they are intended for. Which can make for odd experiences when you install a lot of software from different places. I've found almost all GUI programs are designed to look at home for KDE-qt or GTK, but the difference between what is normal for those two is huge.
Except for a surprising number of file managers that are designed to look like right in the long-dead CDE...

And I can attest that GUI design is definitely not enforced for WIndows Logo certification. Mine eyes, they have seen the horrors that await the adventurous.

As long as it makes sense and isn't obnoxious, I'm sure the community will not be disappointed. Remember that this is replacing an editor that in many situations lacked an undo function.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 25, 2013, 11:28:28 pm
Hm, so I'm trying to implement theming for plugins.  My initial experiment with the Sound Test plugin (which oddly has become the designated guinea pig for stuff like this) was successful, it applies the proper colors and font to the listview and toolbar, everything's fine.  That done, I went to update the script plugin and discovered a showstopper in Scintilla: You can't change the backcolor of the control.  Well, you can, and it does change the background, but it still paints the text with a white background, making for a very ugly result.  Haven't done any testing with the FastTextBox yet, maybe I should...
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: mezzoEmrys on August 25, 2013, 11:33:46 pm
Running x64 Windows 7, and attempting to run the Sphere Editor.exe results in it crashing and burning without fail. I've gotten little usable information about what is going wrong so far, and I'm not sure if I may be missing a non-standard system dll or something, or if running from my D: drive is causing the problem. The problem signature in the crash report notes that it is a "System.IO.FileLoadException". Full problem signature can be given if needed.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 25, 2013, 11:38:08 pm
Yeah, the full crash report would help.  FileLoadException sounds like a binary is missing, but can't tell which one without the full report.

Note that you should have .NET 4.5 installed.  I think the current release will work with stock 4.0, but the latest one upped the requirement to 4.5 (mainly due to the latter being an in-place upgrade with bugfixes that could potentially break an app built against 4.0).
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: mezzoEmrys on August 25, 2013, 11:51:18 pm
After installing 4.5 for good measure, the results of the most recent crash:
https://www.dropbox.com/s/9r76nye4my0h9eq/Sphere%20Editor%20Crash.xml (https://www.dropbox.com/s/9r76nye4my0h9eq/Sphere%20Editor%20Crash.xml)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 25, 2013, 11:55:42 pm
That XML file doesn't seem to have much information... what does the exception window say when the crash happens?  I think with .NET errors you can click More Information and it'll show a stack dump, etc.  If you could get that info it'd really help.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: mezzoEmrys on August 26, 2013, 12:02:20 am
Without opening windows, it gives me a "The Sphere Studio has stopped working", with a second window asking me if I want to send more information about the problem, the first of which I linked to, and the third of which is in hex, and the second of which is below:
https://www.dropbox.com/s/4jquz7byj8anpou/WERB36F.tmp.appcompat.txt (https://www.dropbox.com/s/4jquz7byj8anpou/WERB36F.tmp.appcompat.txt)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 26, 2013, 12:15:11 am
Hm, that just seems to be a list of all the DLLs that were loaded into the app, but no indication of which file caused the error.

MSDN describes a FileLoadException as follows: "The exception that is thrown when a managed assembly is found but cannot be loaded."  In other words, the file was found but couldn't be loaded for some reason, which is strange.  Come to think of it, I feel like I've seen that error once or twice while debugging, but I can't remember what caused it...

Here, just for the hell of it, try this, it's a WIP version of the next release.  I can confirm it works for me and isn't missing any files; I use it a lot via PortableApps, so if anything were missing I'd have noticed.
https://docs.google.com/file/d/0BxPKLRqQOUSNUk5IcDJqTjE4NEU/edit?usp=sharing
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: N E O on August 26, 2013, 04:10:36 pm
Maybe the x64 version mezzoEmrys has is trying to load 32-bit libraries?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 26, 2013, 04:13:38 pm
It could be the sound player module. But in that case you can just tell it to continue and you'll be able to load it without the module.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: casiotone on August 27, 2013, 02:15:59 pm
BTW I'm getting the same error when starting the editor:

Code: [Select]
Problem signature:
  Problem Event Name: CLR20r3
  Problem Signature 01: sphere editor.exe
  Problem Signature 02: 1.1.6.0
  Problem Signature 03: 51e9ea2f
  Problem Signature 04: mscorlib
  Problem Signature 05: 4.0.30319.17929
  Problem Signature 06: 4ffa561c
  Problem Signature 07: 26a0
  Problem Signature 08: 0
  Problem Signature 09: System.IO.FileLoadException
  OS Version: 6.1.7600.2.0.0.768.3
  Locale ID: 2057
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt


So I tried building myself so I could debug it. I'm using Xamarin Studio. The project had missing references to ObjectListView so I built that and added it. It's now complaining about the script_edit.png resource:

(http://i.imgur.com/yfqpLDl.png)

Which does exist, so I'm not sure what the problem is.. Any idea?

Edit: Building in VS2012 worked flawlessly and the FileLoadException is no longer thrown. Here's an x86 build that you can try:

http://files.casiotone.org/SphereStudio-vs2012-x86.rar
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 27, 2013, 03:27:57 pm

Edit: Building in VS2012 worked flawlessly and the FileLoadException is no longer thrown. Here's an x86 build that you can try:


The official build is done with VS2012 I'm almost positive.  I know the build I posted earlier in the thread was.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: casiotone on August 27, 2013, 04:18:29 pm
I think I figured out what that error was... it doesn't happen when you run from a fresh build. It happens if you try and run that build in your old Sphere directory - I'm guessing some of the old Sphere files are interfering.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on August 27, 2013, 04:29:53 pm
Ah, makes sense. It's a version conflict with SciLexer.dll I bet.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: mezzoEmrys on August 27, 2013, 06:35:13 pm
The new build seems to work for me, at least running from a distant directory. I'll just have to call it good and hope that this doesn't come up in the next update!
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on August 27, 2013, 06:38:49 pm

The new build seems to work for me, at least running from a distant directory. I'll just have to call it good and hope that this doesn't come up in the next update!


What do you mean by a distant directory? It should just run in a fresh directory you create. If you attempt to merge it with the old Sphere directory and do not overwrite, say, SciLexer.dll you'll get a DLL load exception. Perhaps that was why it was failing for you?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: mezzoEmrys on August 27, 2013, 06:46:22 pm
I was running it from a subdirectory of my main Sphere directory, now i'm running a couple directories down and over. Upon further tests, moving the old versions to the same directory and running them also causes them to fail. Maybe I'm just cursed?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 05, 2013, 03:21:43 pm
Odd, Sphere Studio doesn't appear to run on a clean install of Windows 8.1.  Double-click the icon and nothing happens--not even a crash, just... nothing.  It mysteriously started working again once I started installing my other programs, but I wasn't paying too close attention to which one finally fixed it... may have even been VS.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Mineat on September 06, 2013, 05:44:31 pm
I fixed my problem(the divide by zero error) with the script editor while running it in the same directory as the engine. Seems that you have to edit the JS files directly from notepad and avoid the comment syntax to have it edited in it. However, code completion did not work afterwards. The way new files are made also come with a file error while loading them(can't find ?.*).

I'm running Windows 7 Pro by the way.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: DaVince on September 07, 2013, 02:25:33 am
I wouldn't exactly call using other software because Sphere Studio's editor crashes for you a fix, though... :P
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 07, 2013, 11:55:02 am
Yeah, and he said he's running it from the same folder as the engine, which we've already established you can't do due to DLL conflicts.

The ?.* error is odd though, I'll have to look into that.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on September 07, 2013, 12:15:24 pm

The ?.* error is odd though, I'll have to look into that.


It's been fixed when you moved things over to plugins. Also I have developed a list of bugs while play testing it one day:

Quote

// regressions:
- Name is untitled when loading files.
- Person names no longer updating on copy.
- Renaming doesn't work for file with same name.
- Windowstyle editor clobbered.
- Selecting last tile in a tileset causes an index exception.

// bugs:
- Clicking spriteset frame doesn't set the index in tileset.
- Color picker not selecting old color in font importer.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 07, 2013, 12:34:26 pm
Does that untitled file bug affect all plugins? Because it seems to show the correct filename for me, at least with scripts and maps.  The only time I get an untitled file is when creating a new one (as is expected).
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on September 07, 2013, 05:29:38 pm
Re untitled files:
I see it's just windowstyles and spritesets. Fonts say "Font Importer" when loading up a font.

I can start fixing some of these errors too, just sign on which ones you want to fix and I'll fix the rest.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 07, 2013, 05:59:13 pm
Ill look into the index error on tilesets, what do you mean by the windowstyle editor being clobbered though?  It looked okay in my (admittedly limited) testing...

I can fix the untitled files as well, should be simple enough.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on September 07, 2013, 06:58:16 pm
I get an unhandled exception on the windowstyle plugin as soon as I load a file. Then it asks to continue or quit. 'Quit' will just close the offending tab, and then another unhandled exception pops up, and clicking quit will again close the tab.

I'll personally look into this one to see what's up.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 07, 2013, 07:00:58 pm
That's weird it only closes the tab, doesn't quitting from an exception usually kill the whole process?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on September 07, 2013, 07:03:05 pm
Usually! (I wonder if it being in a plugin has something to do with it?)

I see there is an issue with HelpLabel. It's null, and as is tradition in C# like languages, there were no checks for it being null and thus the crash.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on September 09, 2013, 10:30:31 pm
VS2012 is having issues with names. It cannot compile my code because it cannot recognize this:

Quote

new MapEditPlugin.Components.MapControl();


Which is weird since it compiled just fine before I opened the map editor in the visual designer. It's the designer doing this partly because a plugin and namespace share the same name: MapEditPlugin.

This will be a consistent issue throughout the code until I change all namespaces to not equal the same name as a class in it (or vice versa) in each solution with this issue (I think most of them do). Heh, sometimes refactoring makes code easier to read / more manageable but in this case it won't compile!
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 09, 2013, 10:37:58 pm
Seems like a bug because in a lot of cases I've seen the designer qualify component classes using global:: to avoid ambiguity, but here it's not doing it. I wonder if VS 2013 fixed/will fix this...

Want me to refactor it while I'm doing the other stuff? I haven't gotten started on those bugfixes yet, this might give me some more incentive.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on September 09, 2013, 11:24:39 pm
Sure! Just to let you know it's generally not a good idea to have a namespace and a class share the same name. Ideologically they should mean two separate things, the class is a specific object type (unless it's flagged ambiguous) and a namespace is a general collection that defines a common thread the components do.

Also it's not intuitive to access a class or namespace - IE it won't compile if you try to access a class's static method or access a namespace. Though I do admit, the plugins make it all too simple for this to happen.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 10, 2013, 01:34:02 pm
Indeed there's a distinction, however this case it seemed the most intuitive (and I believe at least one of the pilot plugins used the same convention before I started tinkering, maybe not though): the namespace contains all the stuff belonging to the plugin, which in turn happens to contain a class representing the plugin itself.  The most logical convention in such a case is for them to have the same name.  But yeah, best to refactor it now that we're aware of the issues.

I still call VS bug, though: the language has constructs in place to disambiguate such things, and the designer will indeed load the component without getting confused.  There's no reason it couldn't generate non-ambiguous code when saving it.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 10, 2013, 08:26:17 pm
Alright, I fixed the untitled files and naming collisions (plugins, at least stock ones, should now use SphereStudio.Plugins as a namespace by convention), but I couldn't reproduce the tileset index exception, selecting the last tile works as expected here.  What are the specific steps you did to cause that crash?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on September 10, 2013, 09:32:44 pm
You add a tile, select it, remove the tile, and then click where it was.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on September 10, 2013, 10:58:06 pm
Hm, that's a tough nut to crack.  I tried a few things to fix it, including adding a conditional to SelectTiles() that checks if the selected tile is in range, yet somehow the if condition passed (wtf?!) and it crashed anyway.  I think I'll just fire off a pull request for my other changes and leave this one to you.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: casiotone on September 11, 2013, 03:07:56 pm
I think there's a number of contributing problems with this bug. I've looked into it and not made much progress either, but what I've found:

https://github.com/Radnen/spherestudio/blob/master/MapEditPlugin/MapEditor.cs#L467

In TilesetControl_TileRemoved, it calls TilesetControl.Select to select the tile that has just been removed.

https://github.com/Radnen/spherestudio/blob/master/MapEditPlugin/Components/TilesetControl2.cs#L212

SelectTiles adds -1 to the Selected list when a tile is invalid. This is then checked for in other places, but imo this should be changed to just ignore invalid tiles so a selected value of -1 doesn't have to be handled anywhere else. e.g. instead of

Code: [Select]
if (tile < 0 || tile > Tileset.Tiles.Count - 1) tile = -1;
Selected.Add(tile);


A better solution would be

Code: [Select]
if (tile >= 0 && tile < Tileset.Tiles.Count)
{
  Selected.Add(tile)
}


The code is quite convoluted so I'm not sure on how it all fits together fully yet, so I might be wrong on this, but I don't see a reason to keep invalid selections in the Selected list.

I'm not sure, but I think TilesetControl.RemoveTiles should also remove the tiles from the Selected list, otherwise it can contain invalid tile indexes after removal.

I'm also not sure about this:

https://github.com/Radnen/spherestudio/blob/master/MapEditPlugin/MapEditor.cs#L452

Here, on the TileSelected event, it calls TilesetControl.SelectTiles again. I think this is dead code however, it's not referenced from MapEditor.cs and if it really was being run it would probably cause an infinite loop. I think the first thing to do is to clean up the map editor and tileset code.

Unfortunately when I was fiddling with all these things I still couldn't get it to work!
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on September 11, 2013, 03:33:48 pm
Hmm, I guess I'll recode the tile selection stuff. It was elegant at one point but then there were a series of changes that kinda added code here and there and got kinda got messier as time went on.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: casiotone on September 11, 2013, 04:27:52 pm

Hmm, I guess I'll recode the tile selection stuff. It was elegant at one point but then there were a series of changes that kinda added code here and there and got kinda got messier as time went on.

I know that feeling!
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on September 22, 2013, 04:34:10 pm
No idea if you know about this, but this is what happens with Mono in Linux:

Code: [Select]
Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
  at Sphere_Editor.SubEditors.ProjectTree.Refresh () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.OnEnabledChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.OnParentEnabledChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.OnEnabledChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.OnEnabledChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:set_Enabled (bool)
  at System.Windows.Forms.Form.ShowDialog (IWin32Window owner) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.ShowDialog () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.MessageBox+MessageBoxForm.RunDialog () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.MessageBox/MessageBoxForm:RunDialog ()
  at System.Windows.Forms.MessageBox.Show (System.String text, System.String caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton) [0x00000] in <filename unknown>:0
  at Sphere_Editor.EditorForm.EditorForm_Shown (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.OnShown (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.SetVisibleCore (Boolean value) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.set_Visible (Boolean value) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:set_Visible (bool)
  at System.Windows.Forms.Application.RunLoop (Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext context) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x00000] in <filename unknown>:0
  at Sphere_Editor.Program.Main () [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
  at Sphere_Editor.SubEditors.ProjectTree.Refresh () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.OnEnabledChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.OnParentEnabledChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.OnEnabledChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.OnEnabledChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:set_Enabled (bool)
  at System.Windows.Forms.Form.ShowDialog (IWin32Window owner) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.ShowDialog () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.MessageBox+MessageBoxForm.RunDialog () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.MessageBox/MessageBoxForm:RunDialog ()
  at System.Windows.Forms.MessageBox.Show (System.String text, System.String caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton) [0x00000] in <filename unknown>:0
  at Sphere_Editor.EditorForm.EditorForm_Shown (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.OnShown (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.SetVisibleCore (Boolean value) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.set_Visible (Boolean value) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:set_Visible (bool)
  at System.Windows.Forms.Application.RunLoop (Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext context) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x00000] in <filename unknown>:0
  at Sphere_Editor.Program.Main () [0x00000] in <filename unknown>:0

Unhandled Exception:
System.ArgumentException: Object has been disposed.
  at System.Drawing.Font.ToHfont () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Drawing.Font:ToHfont ()
  at System.Windows.Forms.TextRenderer.MeasureTextInternal (IDeviceContext dc, System.String text, System.Drawing.Font font, Size proposedSize, TextFormatFlags flags, Boolean useMeasureString) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.TextRenderer.MeasureText (System.String text, System.Drawing.Font font) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripMenuItem.CalculatePreferredSize (Size constrainingSize) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripItem.GetPreferredSize (Size constrainingSize) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripDropDownMenu.OnLayout (System.Windows.Forms.LayoutEventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.PerformLayout (System.Windows.Forms.Control affectedControl, System.String affectedProperty) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.PerformLayout () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:PerformLayout ()
  at System.Windows.Forms.ToolStripItem.OnParentChanged (System.Windows.Forms.ToolStrip oldParent, System.Windows.Forms.ToolStrip newParent) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripItem.set_Parent (System.Windows.Forms.ToolStrip value) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem:set_Parent (System.Windows.Forms.ToolStrip)
  at System.Windows.Forms.ToolStripItemCollection.Remove (System.Windows.Forms.ToolStripItem value) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripItem.Dispose (Boolean disposing) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripDropDownItem.Dispose (Boolean disposing) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripMenuItem.Dispose (Boolean disposing) [0x00000] in <filename unknown>:0
  at System.ComponentModel.Component.Finalize () [0x00000] in <filename unknown>:0


Then it crashes. But it does actually show up for a moment.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on December 09, 2013, 06:37:57 am
Trying to build it using Mon (xbuild):

Code: [Select]

/home/jester/Downloads/spherestudio-master/spherestudio-master/Sphere Studio.sln (default targets) ->
(Build target) ->
/home/jester/Downloads/spherestudio-master/spherestudio-master/TaskListPlugin/TaskListPlugin.csproj (default targets) ->
/usr/lib/mono/4.0/Microsoft.CSharp.targets (CoreCompile target) ->

TaskList.cs(186,62): error CS0246: The type or namespace name `BrightIdeasSoftware' could not be found. Are you missing an assembly reference?
TaskList.cs(198,63): error CS0246: The type or namespace name `BrightIdeasSoftware' could not be found. Are you missing an assembly reference?
TaskList.Designer.cs(277,17): error CS0246: The type or namespace name `BrightIdeasSoftware' could not be found. Are you missing an assembly reference?
TaskList.Designer.cs(278,17): error CS0246: The type or namespace name `BrightIdeasSoftware' could not be found. Are you missing an assembly reference?
TaskList.Designer.cs(279,17): error CS0246: The type or namespace name `BrightIdeasSoftware' could not be found. Are you missing an assembly reference?
TaskList.Designer.cs(280,17): error CS0246: The type or namespace name `BrightIdeasSoftware' could not be found. Are you missing an assembly reference?


Any ideas?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on December 09, 2013, 04:55:53 pm
The DLL in the TaskListPlugin/lib folder is not working? Try to reattach the dependency and perhaps it will compile. If not, then I think it may not be mono-compat. It is a plugin anyways and can totally be removed.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on December 09, 2013, 05:41:52 pm
I can't directly edit the sln files on Linux...I'll give it a look on Windows.

The latest build shows the GUI and everything on Linux with mono, it just crashes a moment later. It very almost works!

EDIT:

Huh, now it seems mono can't find schemas.microsoft.com...

I have no idea why that is necessary, but it seems to be absolutely vital? Either way, I did get it to accept the dependency eventually.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on December 10, 2013, 10:43:04 am
Sounds like it needs to validate one of the XML files in the project against an MS schema.  That's my guess, anyway.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on December 10, 2013, 01:14:30 pm
From what I can tell, it's an address used in Microsoft files too. Maybe it's an old one? But that would be weird, mono uses this file for .NET from 2.0 to 4.5.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on December 13, 2013, 02:43:57 am
I made some bugfixes and added a new feature. You can right click on an item in the project tree and then choose to open that folder or file in explorer. What it would do is either open the folder in an explorer window, giving you easy access to that folder in case you want to do some advanced copying or restructuring, etc. If it is a file, it'll try to open it in the default program set up for that file. So images might be opened in photoshop, code in emacs, and game.sgm in a different sphere editor, etc.

I find myself having more time now, and so I'll try to work on a few of my Sphere projects. If there is anything you want to see be added or fixed for this editor, let me know.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: N E O on February 14, 2014, 07:34:27 pm
Just downloaded the latest version (lists as 1.1.6.0) and it won't even open for me. The resulting problem details:

Quote

Problem signature:
  Problem Event Name:   CLR20r3
  Problem Signature 01:   sphere editor.exe
  Problem Signature 02:   1.1.6.0
  Problem Signature 03:   51e9ea2f
  Problem Signature 04:   mscorlib
  Problem Signature 05:   4.0.30319.18444
  Problem Signature 06:   52717edc
  Problem Signature 07:   26fb
  Problem Signature 08:   0
  Problem Signature 09:   System.IO.FileLoadException
  OS Version:   6.1.7601.2.1.0.274.10
  Locale ID:   1033
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789


Running Windows Server 2008 R2 Enterprise SP1. I wouldn't be surprised if it's because I'm missing something like a particular .NET version or something, since Server seems to have reduced consumer capabilities by default in favor of enterprise/server capabilities. Let me know if there's a way to get more information for you for this, thanks!
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on February 14, 2014, 10:13:11 pm
You need .NET 4.5.  I upped the original requirement from 4.0 because 4.0-targetted apps can have major bugs when running on a system with 4.5 installed. (4.5 is in-place upgrade with several breaking changes)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on February 14, 2014, 11:44:03 pm
I think the version here is still 4.0, Lord English. The error is coming from a FileLoadException, likely to do with a faulty config.ini or Sphere path. It's not Neo's mistake, it's just that the current version uploaded has poor handling of files that no longer exist. I've been meaning to update it to a newer version.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on February 19, 2014, 12:34:56 pm
Ah, I wasn't sure if the switch to 4.5 was done before or after you released 1.1.6.0.

Hey, any chance of implementing split-screen support for scripts? Does Scintilla support that?  I don't usually use the functionality as it's not often needed with well-organized code, but I've had a couple scenarios where splitting an editor would be useful (for example, in my huge gamedef script, referencing existing status-effect implementations when creating a new one).  If not no big deal, I just wondered if it was feasible.

On a sidenote: I wholeheartedly recommend upgrading to VS 2013.  It's fully project-compatible with 2012 (projects created in either will open in the other with no conversion/upgrading), the GUI icons are more readily differentiable (folders are yellow again!), and it even has Git support built-in so you don't need to open GitHub just to make a quick commit. :D
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on February 19, 2014, 02:22:02 pm
Uh, you could just move the docked tab to the right or bottom, and boom, split screen. ;)

Also I'm not going to move to VS 2013 right now, I have a professional version of '12 which comes with a lot of neat profiling tools etc. Since I have graduated from college, I have lost the ability to pick up some nice new software. :P
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on February 19, 2014, 02:42:15 pm

Uh, you could just move the docked tab to the right or bottom, and boom, split screen. ;)


You can't open the same file twice, though.  That's the use case I meant, editing one part of a file while referencing a different area.  Not always needed, but when it is, well, small price to pay for self-documenting code. :)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on February 19, 2014, 03:27:50 pm
Oh, I see! I'll think it over and see what I can do.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on February 19, 2014, 03:56:14 pm
Alright, sounds good.  By the way I upgraded the scintilla control to the latest version, just released this past Monday.  Hopefully that fixes a few bugs with the scintilla plugin.  There seems to be a major regression with the fast script editor, though: trying to open any script results in a divide by zero error.  The VS debugger doesn't help either as the error appears to happen inside the editor control.  Thinking its time to retire that plugin?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on February 19, 2014, 05:04:59 pm

Alright, sounds good.  By the way I upgraded the scintilla control to the latest version, just released this past Monday.  Hopefully that fixes a few bugs with the scintilla plugin.  There seems to be a major regression with the fast script editor, though: trying to open any script results in a divide by zero error.  The VS debugger doesn't help either as the error appears to happen inside the editor control.  Thinking its time to retire that plugin?


Yeah, I think it is, the fast script plugin was my experiment at trying something different, but so far scintilla seems the best in terms of performance, and syntax highlighting capabilities.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: pancakes4ever on March 04, 2014, 06:49:31 pm
My search of the forums "studio linux" and "studio wine" didn't yield anything conclusive or rather an answer that I will ignore with blind optimism. Is it possible to run this in wine yet? (Keep in mind, the fact that it may not does not diminish my appreciation of this sweet, sweet project)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on March 04, 2014, 07:15:43 pm
I have tried to run it in Wine, and also to compile it with Mono. It has never worked for me.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on March 04, 2014, 07:18:44 pm
It had partial support in Wine, I know Wine has gone a long ways now, but since I moved this code to .net 4.0+, I doubt it'll have the support it once had.

My best guess honestly is to simply try it out in Wine and tell me how it goes. Try using the newer development versions. Now, it is possible to compile it in mono, but I'll have to do some rework with the form controls (http://www.mono-project.com/WinForms) etc.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: DaVince on March 05, 2014, 06:28:40 pm
You have to compile it in Mono if you want 4.0+ code to work well in Mono. The runtime code that .NET 4.0+ produces is not fully supported by Mono, but if you compile it in Mono to begin with there should be no issues. I actually found this out after having issues with several other .NET programs that wouldn't work on Mono, and it is a known problem.

Still very much willing to test things out for you if you decide to rework those form controls. I'd love for this to be fully cross-platform, as it just looks so much better than the standard editor.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on March 05, 2014, 07:48:22 pm
+1 for a Mono version, too. I tried a couple times to compile it with Mono, but I just do not know enough about the editor, C#, or Mono to make it work.

I would love to have this working in Linux! That would mean I could actually have Sphere 1.6 and a Sphere editor running on my computers without Wine!
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: pancakes4ever on March 14, 2014, 02:17:48 pm
+1 mono. I tried it yesterday with both wine and mono. Mono got me closer it seems to open window components but freezes up trying to display content within those windows. Judging by the last couple posts, it doesnt work under it yet...
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on March 18, 2014, 06:59:51 pm
So I just did some reformatting and moved some plugins over to the official unoffical Sphere Studio plugin repository.

Here: https://github.com/sphere-group/sphere-studio-plugins

So if anyone wants to make a plugin, they can start there. I hopefully made it easy to make plugins. I'm planning on making an irc plugin for Sphere Studio; I just need to find a good irc library and then create a plugin for it. ;)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on March 19, 2014, 06:55:28 pm
Are there any plans for a subversion or Git plugin?

Because that would be really cool!

If you make one, a rich sub-plugin system would be nice, too. The ability to dynamically generate or modify git repos to include submodules that contain the plugins required for the game when used on a plugin-based Sphere engine, depending on what plugins the game needs, would be some seriously cool and powerful stuff!
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Rahkiin on March 19, 2014, 07:04:05 pm

Are there any plans for a subversion or Git plugin?

Because that would be really cool!

If you make one, a rich sub-plugin system would be nice, too. The ability to dynamically generate or modify git repos to include submodules that contain the plugins required for the game when used on a plugin-based Sphere engine, depending on what plugins the game needs, would be some seriously cool and powerful stuff!


+1.

I support this idea! Even though I can't use the editor :P I will implement it in my own IDE.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on March 19, 2014, 07:31:25 pm
It's funny, because the thought crossed my mind to make a git plugin for Sphere Studio.  Git support is built into VS 2013 now, and it's really nice to have it built into the IDE like that.  But I didn't do it because it would be a ton of work and I really want to concentrate on Specs at present.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Rahkiin on March 19, 2014, 07:54:04 pm
Git is also integrated in since Xcode 4 (but it sucked ballz back then). Now it is quite nice.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on March 19, 2014, 08:38:54 pm

If you make one, a rich sub-plugin system would be nice, too. The ability to dynamically generate or modify git repos to include submodules that contain the plugins required for the game when used on a plugin-based Sphere engine, depending on what plugins the game needs, would be some seriously cool and powerful stuff!


I can a kind of dependency management system like what Node.js has. Games require files that exist on the Sphere downloads repo and are downloaded when the game is 'built' on the machine. It could aid in shrinking the overall library code in your repository. For Lord English's game, he could use something like this to separate kh2bar, link, analogue, etc. from his own code.

But that's still some time away. My priorities are not on the editor right now, even though I'd love to do more plugins.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: N E O on March 21, 2014, 09:27:08 am
Re dependency management - that's the exact reason I pushed so hard back in the day for Flik to add /common directory support to the file management functions. I'll likely write an official recommendation for this in the Sphere-compatible wiki article once I'm on a PC but in the meantime I'll declare here any dependent resource management system written for Sphere should ideally download to a subdirectory of a given format inside the common directory pointed to by Sphere.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Rahkiin on March 21, 2014, 12:49:38 pm
I'd like to disagree.

I propose the following format:

spritesets/
maps/
...
scripts/
    main.js
libraries/
    link/
        scripts/
            link.js
        maps/
        spritesets/
        ....
        package.json
    persist/
        scripts/
            persist.js
        package.json

Then we can use git submodules to add modules to our source code (a module in the library/ folder) and use gitmodule init and update to download the data. One can then export the project by just copying all the files (except the .git folder in the root of course). As a sidenote, I think downloading at runtime of the game should never be done.

// Rahkiin
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: N E O on March 22, 2014, 05:48:35 pm
@Rahkiin - I don't understand what you're disagreeing with. If you could elaborate on what your proposed file structure is meant to replace so I can respond to it directly that'd be great, thanks :)

Until then, I'll elaborate on the existence of the /common directory:



The intent of the /common directory is to allow separate distribution of resources and libraries intended to be global but not officially included as system resources to ease the necessity of updating every single project that uses them. Ideally the files would be put into the /common directory in a consistent structure (either like /common/some-username/scripts/somelibrary.js or /common/scripts/some-username-somelibrary.js or similar depending on the resource's type) similar to that of a normal Sphere project and users would then reference the common file path using the resource's non-system loading function (e.g. Tung's persist.js would be placed in /common/tung/scripts/persist.js and the script would be loaded using RequireScript("/common/tung/scripts/persist.js"); in a project, a font "Square 1" packaged by myself would be placed in /common/neologix/fonts/square1.rfn and loaded in script using LoadFont("/common/neologix/fonts/square1.rfn"), etc).

From anecdotal evidence (IIRC) not many users actually used /common (I'm still under the assumption it was due to lack of advertisement of the feature), opting to instead package local copies of specific versions of scripts known to work with particular projects, but it's been used: Flik afterwards put most or all his non-system flik_* scripts into common file format, Radnen did it once or twice with some RadLib stuff, Flying Jester I think intended to put Majestic in there once, and I myself created an assortment of different resources (https://web.archive.org/web/20120827090918/http://www.spheredev.org/wiki/Common_files_package) to be used freely and commonly (not quite an RPGMaker RTP, but still a thing) from /common. I didn't yet restore the "Common files package" article because I wanted to first generalize the process of coming up with a common file and/or package then put my specific package in a separate article and reference a list of resources prepped for /common directory placement.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on March 22, 2014, 06:06:14 pm
I didn't tend to use /common because it was local to your machine and made the distribution of your game's code tricky. But it is definitely a place to put libraries if the editor were to download them for you and put them in there. But, then we have git.

A lot of people like me put their games on github, so the same directory for your game is also the git repo, making /common inaccessible. Further, you can have git sub-modules in your repo, putting them in a /libraries folder like Rahkiin suggested is a good idea for something like this. Therefore I don't see /common a practical thing in the modern day of Sphere. Especially since with git you can clone a git repo, then require all the dependencies (sub-modules) you need.

But! /common's structure for other Sphere filetypes is not bad at all. There's just got to be a way of making it friendlier to games hosted on repositories. Now, Rahkiin on IRC has stated his Load* functions will check in /libraries for his engine. Which is not a bad idea for loading those other types like maps and fonts. But of course that's only going to be a feature unique to his engine.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Rahkiin on March 22, 2014, 06:41:23 pm
Right. What she said.

As Radnen said, my idea of the libraries folder is to be able to ship it. My own game engine will ship with a single game in a complete package. I won't ship multiple games in an engine so I don't have such thing as common/. @Neo, when you said common/, I thought you meant the same thing as my libraries/, but with another name.
The use of SCM with a common/ folder is very troublesome, as it breaks everything.

To elaborate on my Load idea:

My load functions, actually any function dealing with resolving of paths, is using a resource path resolver. It always uses the same order of files. (This is not set in stone yet).
Example, loading a font, LoadFont('myFont') / new Font('myFont') (note the missing extension, because it is not needed for fonts).
[li]
[/li][/list]

(I will have to figure out what the best order is: maybe like DLLs, local overwriting system, thus ./ as first...)
Now it is a bit more complex than that: when a library loads a file, it will first look in the own library folder, then in other libraries, and not using the game folder.

This can of course be implemented by any engine.

I had the idea of remapping ~/ and / too, because I want the file system of the game to be sandboxed. It is so easy to screw things up with the file api. I probably need to have a pointer to the User's library folder (on mac) to store game data like savegames, because an application can't just write in its own folder (IIRC). Mapping / to the game and ~/ to the User Application Data is usable i think (~/ is normally /home/USER, and / is the system. The idea fits.)
As a sidenote: in my resource path resolver, when prefixing with ~/ or /, the path is 'absolute'.


I hope this helps.

// Rahkiin
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: N E O on March 22, 2014, 07:51:00 pm
@Neo, when you said common/, I thought you meant the same thing as my libraries/, but with another name.


Then you'd pretty much be right about that, except if I read you correctly your libraries/ directory concept pretty much equates to a game-local version of the existing /common directory implementation instead of a global one. For now, you might be best served by calling RequireScript("~/libraries/tung/scripts/persist.js"); or LoadFont("~/libraries/neologix/fonts/square1.rfn") .

Re directory mappings - while at the moment the directory mappings /, ~/, and /common are all relative to the location of the Sphere executable (likely also the case on the current v1.5 Mac version), I'm definitely open to adding to Config the ability to set where / and /common map to, though if ~/ were to map to a location different from the calling script's project there would need to be a discussion about the pros & cons of changing the existing behavior and exposing that mapping to Config.

Re /common and version control - I indeed came up with the suggestion before version control became easy and more mainstream. All we had at the time was CVS and SVN, with Perforce as the crappy commercial alternative; git was barely more than Linus's pet project limited to versioning Linux, Mercurial pretty much didn't yet exist, and Sourceforge was the only decent public source code repository. With the proliferation of public source repository sites like Github and Bitbucket, it's way easier to add something external as a dependency and have the ability to handle it separately.

While I'd prefer users leverage existing functionality, if some functionality is useful and not yet implemented in any capacity or is implemented poorly I'd much rather people make requests (which you are doing, thanks :) ) than stay silent or just complain with no solution.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Rahkiin on March 22, 2014, 08:38:45 pm
We can of course work together (Radnen, FJ and me) to put this functionality in the newer engines and editors and see how that works out.

The remapping of ~/ to not something in the game folder is because of the permissions in Mac and because there is already a / to point to the game folder. Pretty reasonable I think. On windows it would point to /Users/<name>/App Data/Local/<game name>/ (i think :P)

// Rahkiin
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on April 02, 2014, 12:08:26 am
I get this error when I try to run Sphere Studio (natively on Windows for a change):

Code: [Select]

Files that help describe the problem:
  C:\Users\Jester\AppData\Local\Temp\WERAAA1.tmp.WERInternalMetadata.xml
  C:\Users\Jester\AppData\Local\Temp\WERC035.tmp.appcompat.txt
  C:\Users\Jester\AppData\Local\Temp\WERC045.tmp.mdmp

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt


Code: [Select]


<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="Sphere Editor.exe" FILTER="CMI_FILTER_PRIVACY">
    <MATCHING_FILE NAME="FastColoredTextBox.dll" SIZE="274944" CHECKSUM="0xFCD74821" BIN_FILE_VERSION="2.9.8.0" BIN_PRODUCT_VERSION="2.9.8.0" PRODUCT_VERSION="2.9.8.0" FILE_DESCRIPTION="FastColoredTextBox" COMPANY_NAME="Pavel Torgashov" PRODUCT_NAME="FastColoredTextBox" FILE_VERSION="2.9.8.0" ORIGINAL_FILENAME="FastColoredTextBox.dll" INTERNAL_NAME="FastColoredTextBox.dll" LEGAL_COPYRIGHT="© Pavel Torgashov, 2011-2013, pavel_torgashov@mail.ru." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="2.9.8.0" UPTO_BIN_PRODUCT_VERSION="2.9.8.0" LINK_DATE="03/03/2013 11:18:37" UPTO_LINK_DATE="03/03/2013 11:18:37" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="ikpFlac.dll" SIZE="159744" CHECKSUM="0xC268E38B" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2CAF7" LINKER_VERSION="0x0" LINK_DATE="05/31/2012 09:33:27" UPTO_LINK_DATE="05/31/2012 09:33:27" EXPORT_NAME="ikpFlac.dll" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="ikpMP3.dll" SIZE="163840" CHECKSUM="0xD7220828" BIN_FILE_VERSION="0.0.0.3" BIN_PRODUCT_VERSION="0.0.0.3" PRODUCT_VERSION="0, 0, 0, 3" FILE_DESCRIPTION="ikpMP3 Dynamic Link Library" COMPANY_NAME="ambiera" PRODUCT_NAME=" ikpMP3 Dynamic Link Library" FILE_VERSION="0, 0, 0, 3" ORIGINAL_FILENAME="ikpMP3.dll" INTERNAL_NAME="ikpMP3" LEGAL_COPYRIGHT="Copyright (C) 2006-2007 N.Gebhardt, LGPL licensed" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2CD50" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="0.0.0.3" UPTO_BIN_PRODUCT_VERSION="0.0.0.3" LINK_DATE="05/31/2012 09:33:22" UPTO_LINK_DATE="05/31/2012 09:33:22" EXPORT_NAME="ikpMP3.dll" VER_LANGUAGE="German (Germany) [0x407]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="irrKlang.NET4.dll" SIZE="501760" CHECKSUM="0x526635C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x88A4D" LINKER_VERSION="0x0" LINK_DATE="05/31/2012 13:24:35" UPTO_LINK_DATE="05/31/2012 13:24:35" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="ObjectListView.dll" SIZE="407040" CHECKSUM="0xFEF9ECDF" BIN_FILE_VERSION="2.5.1.0" BIN_PRODUCT_VERSION="2.5.1.0" PRODUCT_VERSION="2.5.1.0" FILE_DESCRIPTION="ObjectListView" COMPANY_NAME="Bright Ideas Software" PRODUCT_NAME="ObjectListView" FILE_VERSION="2.5.1.0" ORIGINAL_FILENAME="ObjectListView.dll" INTERNAL_NAME="ObjectListView.dll" LEGAL_COPYRIGHT="Copyright ©  2006-2012" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6636F" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="2.5.1.0" UPTO_BIN_PRODUCT_VERSION="2.5.1.0" LINK_DATE="04/08/2013 19:36:32" UPTO_LINK_DATE="04/08/2013 19:36:32" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="SciLexer.dll" SIZE="648704" CHECKSUM="0xDA22A146" BIN_FILE_VERSION="3.0.4.0" BIN_PRODUCT_VERSION="3.0.4.0" PRODUCT_VERSION="3.0.4" FILE_DESCRIPTION="Scintilla.DLL - a Source Editing Component" COMPANY_NAME="Neil Hodgson neilh@scintilla.org" PRODUCT_NAME="Scintilla" FILE_VERSION="3.0.4" ORIGINAL_FILENAME="Scintilla.DLL" INTERNAL_NAME="Scintilla" LEGAL_COPYRIGHT="Copyright 1998-2012 by Neil Hodgson" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="3.0.4.0" UPTO_BIN_PRODUCT_VERSION="3.0.4.0" LINK_DATE="03/27/2012 20:29:11" UPTO_LINK_DATE="03/27/2012 20:29:11" EXPORT_NAME="SciLexer.dll" VER_LANGUAGE="English (United States) [0x409]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="ScintillaNET.dll" SIZE="582144" CHECKSUM="0x8A9D984" BIN_FILE_VERSION="2.5.2.0" BIN_PRODUCT_VERSION="2.5.2.0" PRODUCT_VERSION="2.5.2.0" FILE_DESCRIPTION="ScintillaNET" COMPANY_NAME="ScintillaNET Team" PRODUCT_NAME="ScintillaNET" FILE_VERSION="2.5.2.0" ORIGINAL_FILENAME="ScintillaNET.dll" INTERNAL_NAME="ScintillaNET.dll" LEGAL_COPYRIGHT="Copyright (C) 2012 ScintillaNET. All rights reserved." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x9A069" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="2.5.2.0" UPTO_BIN_PRODUCT_VERSION="2.5.2.0" LINK_DATE="08/27/2012 01:37:04" UPTO_LINK_DATE="08/27/2012 01:37:04" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Sphere Editor.exe" SIZE="557568" CHECKSUM="0xD1D6A4B0" BIN_FILE_VERSION="1.1.6.0" BIN_PRODUCT_VERSION="1.1.6.0" PRODUCT_VERSION="1.1.6.0" FILE_DESCRIPTION="The Sphere Studio" COMPANY_NAME="Spherical" PRODUCT_NAME="Sphere Studio" FILE_VERSION="1.1.6.0" ORIGINAL_FILENAME="Sphere Editor.exe" INTERNAL_NAME="Sphere Editor.exe" LEGAL_COPYRIGHT="Copyright ©  2012 - Spherical" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.1.6.0" UPTO_BIN_PRODUCT_VERSION="1.1.6.0" LINK_DATE="07/20/2013 01:38:55" UPTO_LINK_DATE="07/20/2013 01:38:55" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Sphere.Core.dll" SIZE="71680" CHECKSUM="0x77FCCE66" BIN_FILE_VERSION="1.0.0.0" BIN_PRODUCT_VERSION="1.0.0.0" PRODUCT_VERSION="1.0.0.0" FILE_DESCRIPTION="Sphere.Core" PRODUCT_NAME="Sphere.Core" FILE_VERSION="1.0.0.0" ORIGINAL_FILENAME="Sphere.Core.dll" INTERNAL_NAME="Sphere.Core.dll" LEGAL_COPYRIGHT="Copyright ©  2013" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.0" UPTO_BIN_PRODUCT_VERSION="1.0.0.0" LINK_DATE="07/05/2013 00:49:43" UPTO_LINK_DATE="07/05/2013 00:49:43" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Sphere.Plugins.dll" SIZE="7680" CHECKSUM="0xBA3D8B99" BIN_FILE_VERSION="1.0.0.0" BIN_PRODUCT_VERSION="1.0.0.0" PRODUCT_VERSION="1.0.0.0" FILE_DESCRIPTION="Sphere.Plugins" PRODUCT_NAME="Sphere.Plugins" FILE_VERSION="1.0.0.0" ORIGINAL_FILENAME="Sphere.Plugins.dll" INTERNAL_NAME="Sphere.Plugins.dll" LEGAL_COPYRIGHT="Copyright ©  2013" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.0" UPTO_BIN_PRODUCT_VERSION="1.0.0.0" LINK_DATE="07/05/2013 00:49:44" UPTO_LINK_DATE="07/05/2013 00:49:44" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="WeifenLuo.WinFormsUI.Docking.dll" SIZE="425472" CHECKSUM="0xAD8DF3D" BIN_FILE_VERSION="2.7.0.0" BIN_PRODUCT_VERSION="2.7.0.0" PRODUCT_VERSION="2.7.0.0" FILE_DESCRIPTION="DockPanel Suite for .Net" COMPANY_NAME="Weifen Luo" PRODUCT_NAME="DockPanel Suite" FILE_VERSION="2.7.0.0" ORIGINAL_FILENAME="WeifenLuo.WinFormsUI.Docking.dll" INTERNAL_NAME="WeifenLuo.WinFormsUI.Docking.dll" LEGAL_COPYRIGHT="Copyright © Weifen Luo and other contributors 2007-2012" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x6F809" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="2.7.0.0" UPTO_BIN_PRODUCT_VERSION="2.7.0.0" LINK_DATE="04/14/2013 20:28:38" UPTO_LINK_DATE="04/14/2013 20:28:38" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Plugins\FastScriptPlugin.dll" SIZE="18432" CHECKSUM="0x4156CA4A" BIN_FILE_VERSION="1.0.0.0" BIN_PRODUCT_VERSION="1.0.0.0" PRODUCT_VERSION="1.0.0.0" FILE_DESCRIPTION="FastScriptPlugin" PRODUCT_NAME="FastScriptPlugin" FILE_VERSION="1.0.0.0" ORIGINAL_FILENAME="FastScriptPlugin.dll" INTERNAL_NAME="FastScriptPlugin.dll" LEGAL_COPYRIGHT="Copyright ©  2013" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.0" UPTO_BIN_PRODUCT_VERSION="1.0.0.0" LINK_DATE="07/05/2013 00:49:45" UPTO_LINK_DATE="07/05/2013 00:49:45" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Plugins\FontPlugin.dll" SIZE="32768" CHECKSUM="0xA90DA9A1" BIN_FILE_VERSION="1.0.0.0" BIN_PRODUCT_VERSION="1.0.0.0" PRODUCT_VERSION="1.0.0.0" FILE_DESCRIPTION="FontPlugin" PRODUCT_NAME="FontPlugin" FILE_VERSION="1.0.0.0" ORIGINAL_FILENAME="FontPlugin.dll" INTERNAL_NAME="FontPlugin.dll" LEGAL_COPYRIGHT="Copyright ©  2013" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.0" UPTO_BIN_PRODUCT_VERSION="1.0.0.0" LINK_DATE="07/05/2013 00:49:44" UPTO_LINK_DATE="07/05/2013 00:49:44" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Plugins\MyPlugin.dll" SIZE="5632" CHECKSUM="0xCD89C3E2" BIN_FILE_VERSION="1.0.0.0" BIN_PRODUCT_VERSION="1.0.0.0" PRODUCT_VERSION="1.0.0.0" FILE_DESCRIPTION="MyPlugin" PRODUCT_NAME="MyPlugin" FILE_VERSION="1.0.0.0" ORIGINAL_FILENAME="MyPlugin.dll" INTERNAL_NAME="MyPlugin.dll" LEGAL_COPYRIGHT="Copyright ©  2013" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.0" UPTO_BIN_PRODUCT_VERSION="1.0.0.0" LINK_DATE="07/05/2013 00:49:44" UPTO_LINK_DATE="07/05/2013 00:49:44" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Plugins\ScriptPlugin.dll" SIZE="24064" CHECKSUM="0x3381B852" BIN_FILE_VERSION="1.0.0.0" BIN_PRODUCT_VERSION="1.0.0.0" PRODUCT_VERSION="1.0.0.0" FILE_DESCRIPTION="ScriptPlugin" PRODUCT_NAME="ScriptPlugin" FILE_VERSION="1.0.0.0" ORIGINAL_FILENAME="ScriptPlugin.dll" INTERNAL_NAME="ScriptPlugin.dll" LEGAL_COPYRIGHT="Copyright ©  2013" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.0" UPTO_BIN_PRODUCT_VERSION="1.0.0.0" LINK_DATE="07/05/2013 00:49:44" UPTO_LINK_DATE="07/05/2013 00:49:44" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Plugins\SoundTestPlugin.dll" SIZE="24576" CHECKSUM="0x8D8604D6" BIN_FILE_VERSION="1.0.0.0" BIN_PRODUCT_VERSION="1.0.0.0" PRODUCT_VERSION="1.0.0.0" FILE_DESCRIPTION="MyPlugin" PRODUCT_NAME="MyPlugin" FILE_VERSION="1.0.0.0" ORIGINAL_FILENAME="SoundTestPlugin.dll" INTERNAL_NAME="SoundTestPlugin.dll" LEGAL_COPYRIGHT="Copyright ©  2013" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.0" UPTO_BIN_PRODUCT_VERSION="1.0.0.0" LINK_DATE="07/05/2013 00:49:44" UPTO_LINK_DATE="07/05/2013 00:49:44" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
    <MATCHING_FILE NAME="Plugins\TaskPlugin.dll" SIZE="39424" CHECKSUM="0xF8AE30BD" BIN_FILE_VERSION="1.0.0.0" BIN_PRODUCT_VERSION="1.0.0.0" PRODUCT_VERSION="1.0.0.0" FILE_DESCRIPTION="TaskPlugin" PRODUCT_NAME="TaskPlugin" FILE_VERSION="1.0.0.0" ORIGINAL_FILENAME="TaskPlugin.dll" INTERNAL_NAME="TaskPlugin.dll" LEGAL_COPYRIGHT="Copyright ©  2013" VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.0" UPTO_BIN_PRODUCT_VERSION="1.0.0.0" LINK_DATE="07/05/2013 00:49:44" UPTO_LINK_DATE="07/05/2013 00:49:44" VER_LANGUAGE="Language Neutral [0x0]" EXE_WRAPPER="0x0" />
</EXE>
<EXE NAME="KERNELBASE.dll" FILTER="CMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="KernelBase.dll" SIZE="274944" CHECKSUM="0x46F98ADE" BIN_FILE_VERSION="6.1.7601.18229" BIN_PRODUCT_VERSION="6.1.7601.18229" PRODUCT_VERSION="6.1.7601.18015" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="6.1.7601.18015 (win7sp1_gdr.121129-1432)" ORIGINAL_FILENAME="Kernelbase" INTERNAL_NAME="Kernelbase" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x4F697" LINKER_VERSION="0x60001" UPTO_BIN_FILE_VERSION="6.1.7601.18229" UPTO_BIN_PRODUCT_VERSION="6.1.7601.18229" LINK_DATE="08/02/2013 01:53:26" UPTO_LINK_DATE="08/02/2013 01:53:26" EXPORT_NAME="KERNELBASE.dll" VER_LANGUAGE="English (United States) [0x409]" EXE_WRAPPER="0x0" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="CMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="kernel32.dll" SIZE="1114112" CHECKSUM="0x2325986C" BIN_FILE_VERSION="6.1.7601.18229" BIN_PRODUCT_VERSION="6.1.7601.18229" PRODUCT_VERSION="6.1.7601.18015" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="6.1.7601.18015 (win7sp1_gdr.121129-1432)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x111A9F" LINKER_VERSION="0x60001" UPTO_BIN_FILE_VERSION="6.1.7601.18229" UPTO_BIN_PRODUCT_VERSION="6.1.7601.18229" LINK_DATE="08/02/2013 01:53:25" UPTO_LINK_DATE="08/02/2013 01:53:25" EXPORT_NAME="KERNEL32.dll" VER_LANGUAGE="English (United States) [0x409]" EXE_WRAPPER="0x0" FILE_ID="0000e0bef3b185aaeb915285724dd6e1ff5b66051489" PROGRAM_ID="0000f519feec486de87ed73cb92d3cac802400000000" />
</EXE>
</DATABASE>


I'd really like to get this working. I kind of want to distribute a version of Sphere 1.6 compiled with MSVC 2010, using FJ-GL as the default graphics plugin, and with your editor.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on April 02, 2014, 01:23:21 am
Do you have .Net 4.0?
What version windows do you have?
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on April 02, 2014, 02:05:14 am
Windows 7, 64-bit, .NET 4.5.1 installed.

I also tried to run the .NET 4 installer (I recall, back in the day, .NET versions not being cumulative), but the installer told me it was unnecessary.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on April 02, 2014, 11:19:44 am
4.5 and 4.5.1 are in-place upgrades for 4.0.  If you have either, you already have 4.0.  Microsoft changed their .NET upgrade system with 4.x, major versions are distinct but point upgrades are cumulative.  That's why I re-targeted Studio to 4.5, because from what I understand, 4.5 fixes several bugs that can seriously break things when a 4.0-targeted app is run on a machine with 4.5 installed.

In any case, that looks like a hard crash (segfault), not a .NET exception, which is quite odd.  Never seen that happen before.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on February 23, 2015, 02:49:16 am
It's been a while since I've done anything, so figured I'd contribute a token fix to Sphere Studio: Support for setting the repeat/toric flag on maps.  Up till now, the Repeat Map checkbox in Studio did nothing, presumably due to the flag being undocumented in the RMP spec... a quick look at the Sphere 1.5 source was all that was needed though. :)

Just waiting for Radnen to accept the pull request.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on February 23, 2015, 08:22:04 pm
Nice find.

I have been thinking about this editor and I'm planning on adding a "save workspace" feature. It'll happen automatically and basically saves the currently opened tabs. I've always hated closing everything and then reopening files whenever I open the editor. This means I'll need to create a file for the editor. An actual project file (something you would not save to git).

Should it be:
- XML
- JSON
- INI
- YML

I'm leaning to XML, but Sphere loves ini and you could do something fun with the game reading the ini (for running the currently editing map, a feature that actually is in Sphere 1.5 through the old editor, of course this doesn't have to be in an .ini, just as a new cmd line operation).

There are also quite a few bugs still on my to-do list, with renaming files, making new windowstyles through the project tree (I mean wtf happened here? :P), etc.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on February 23, 2015, 08:34:09 pm
I would far prefer JSON over XML.

JSON would also be very easy to manipulate from JS, even from the JS that Sphere 1.5 uses. It would be a big step up over INI, but still much easier to manipulate from script than XML while providing a quite similar feature-set.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on February 25, 2015, 09:48:52 am
This is a great idea.  I would also recommend while you're at it to have it remember the state of the project tree, i.e. which folders are expanded and collapsed.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on February 25, 2015, 12:15:40 pm
Ok, cool, I'm not sure on using JSON though since I would need to add a JSON parsing library to C#... Maybe I'll have a "project format" option and you can choose between xml, json, and ini. I'll create this feature as a Sphere Editor Plugin... maybe, maybe it'll be core to the editor since it'll also store the editor settings too (so you can choose which sphere engine to use for your game when developing, on a per-game basis).

Do you want the project file to have a specific file extension or if it's xml (.xml), json (.json), ini (.ini)? If not I might do .spf, for "Sphere Project File", fits into the .spk, .sgm scheme, and it protects against harmful UV rays. (Also why do files have .r in them? .rss, .rmp, .rfn, .rts, .rws)
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on February 25, 2015, 12:18:50 pm
Quote
RPG Map File Format
Chad Austin
10.3.1999


It's for "RPG".
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on February 25, 2015, 12:19:44 pm
Oh, haha I never realized. :P
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on March 17, 2015, 10:37:11 am
Hey Radnen, I fixed a bunch of glitches with the new config picker about a week ago, just waiting on you to pull in the changes.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on March 17, 2015, 10:33:04 pm
Huh, I thought I did merge it. Guess I only reviewed the code. :P
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Flying Jester on March 28, 2015, 11:06:32 pm
When was the latest zip on tengudev updated?

I'm still getting the same crashes I was before.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on March 30, 2015, 10:43:25 am
That zip is pretty old, I'd wager.  I know I've contributed a couple new features (like an engine picker) since that was posted.  Sphere Studio could probably do with a version bump at this point, honestly.

The crashes I'm assuming are due to from what I consider to be a shortage of internal sanity checks in the code.  It works fine for me, but depending on configuration, maybe there's something in your setup that trips it up.  At some point someone should probably go through it to make it more robust against errors...
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Radnen on March 30, 2015, 08:14:20 pm
@Jester if you are adventurous enough, try compiling it in VS 2013 community, it's a completely free version of it w/ all the bells and whistles.

@Lord English: yeah, a version bump would be nice about now. Let me go do that and create a new release.
Title: Re: Radnen's Sphere Studio v1.1.6.0
Post by: Fat Cerberus on March 30, 2015, 09:42:30 pm

@Lord English: yeah, a version bump would be nice about now. Let me go do that and create a new release.


Before you do that, check your pull requests.  I just fixed a map editor crash caused by oversized tiles.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on March 31, 2015, 12:06:14 am
Version 1.1.7.0 is out, it contains new features and lots of bug fixes that Lord English and I added.

Features
1. Quick Profile Selector (quickly go between your favorite sphere engines)
2. "Open With..." Support (or drag + drop on executable support, or cmd-line support)

Bug fixes:
1. Various fixes to the editors
2. Many fixes to the project tree (renaming, copying, importing, etc)

Get while it's hot!
https://www.dropbox.com/s/sl8af7flknll4mp/SphereStudio1.1.7.0.zip?dl=0
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on March 31, 2015, 12:30:33 am
I get the following error on trying to run the new version:

Code: [Select]

Jester@olympic /cygdrive/c/Users/Jester/Downloads/SphereStudio1.1.7.0
$ ./Sphere\ Studio.exe

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Users\Jester\Downloads\SphereStudio1.1.7.0\Plugins\FontEditPlugin.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
   --- End of inner exception stack trace ---
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at SphereStudio.Global.EvalPlugins()
   at SphereStudio.IDEForm..ctor()
   at SphereStudio.Program.Main(String[] args)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on March 31, 2015, 12:32:51 am
That's an odd error, something about sandboxing.

I know what it is, the "downloaded from Internet" security flag is probably interfering with it.  You'll have to remove that attribute.  The quickest way is to copy the files to a FAT32 drive and back again.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on March 31, 2015, 12:45:14 am
Alright, just strip the FS attributes. I can do that.
Even easier is just zipping and then unzipping again. Which illustrates a part of why I dislike zip :)

It works now. So, that was probably what kept me from using this editor for over a year.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on March 31, 2015, 10:39:50 am
@Radnen: How did you get the profile selector to stop looking like a Win95 control (and stop flickering, thank goodness)?  I tried to fix that myself, but I couldn't figure it out.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on March 31, 2015, 08:08:01 pm

@Radnen: How did you get the profile selector to stop looking like a Win95 control (and stop flickering, thank goodness)?  I tried to fix that myself, but I couldn't figure it out.


It bugged the crap out of me too! :P I just tapped my monitor with a magic wand (flat style: standard).

I also gave people proper credit in the About section, and bumped the copyright to 2015, since it said 2013 on it, which feels like... yesterday since all the code came back to me as if I left off then. :P
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on March 31, 2015, 08:09:12 pm
Oh by the way I just implemented a layer properties form. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on March 31, 2015, 08:19:34 pm

I also gave people proper credit in the About section, and bumped the copyright to 2015, since it said 2013 on it, which feels like... yesterday since all the code came back to me as if I left off then. :P


A sign of good code ;)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on March 31, 2015, 08:21:44 pm


I also gave people proper credit in the About section, and bumped the copyright to 2015, since it said 2013 on it, which feels like... yesterday since all the code came back to me as if I left off then. :P


A sign of good code ;)


It helped that 90% of the editor was in plugins with the other 10% being the project tree and the settings dialog. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 03, 2015, 09:58:13 pm
So I finally decided to work on that hex editor plugin I mentioned a while back (it's still under development).  This will allow Sphere Studio to view/edit any type of file in hex mode, which might come in handy for advanced users.

I know I've had to use a hex editor to open a Sphere file a couple of times, and not only during minisphere development either.  The vanilla engine especially is full of bugs, so being able to see the raw data of, say, a map file has its merits. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on April 03, 2015, 10:51:19 pm

So I finally decided to work on that hex editor plugin I mentioned a while back (it's still under development).  This will allow Sphere Studio to view/edit any type of file in hex mode, which might come in handy for advanced users.


And that is why I made it recognize plugins. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 04, 2015, 01:32:48 am
And here's a screenshot. ;D
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on April 04, 2015, 03:50:15 am
Are you going to create that as an offshoot project from Sphere Studio? Because, I didn't want plugins to be belong with the same source as the editor. (besides the official plugins, of course). Your sound player I do consider an official plugin for fulfilling the role of a sound tester, because I think it needed one. Other than that, this hex editor is optional and I want to start seeing separated community uploaded plugins.

So, you could create a new topic I guess with the download. Installing a plugin for an end user only requires they put the DLL into the /plugins sub-directory and any associated DLLs into the root folder.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: DaVince on April 04, 2015, 07:11:36 am
Looks super neat! I was wondering if you could highlight things in the Sphere files (like headers, image data etc.) with special colors, and indicate in the status bar what the selected value exactly is. Heck, could even go as far as popping up a little image if you selected graphics data inside one of the Sphere files.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: DaVince on April 04, 2015, 07:31:18 am
I decided to give Sphere Studio another shot in Wine again, just to see how far I come! Well, I've got good news and bad news.

(http://i.imgur.com/cXUxr4T.png)

The editor opens! And it looks the way it should! There are no issues with the visuals other than tooltips not appearing (instead, the main window loses focus in order to focus on this invisible tooltip.) Actually - just noticed it sometimes does show the tooltip, but the content of it lags behind and would show the content of the previous thing I pointed at. It also disappears pretty quickly (less than half a second).

Whenever I try to open the Editor Settings, I am confronted with a runtime error:
Code: [Select]
See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.MissingMethodException: Method not found: 'System.Collections.Generic.IReadOnlyDictionary`2<System.String,Sphere.Core.Editor.StyleGroup> Sphere.Core.Editor.StyleSettings.get_Styles()'.
   at SphereStudio.Forms.EditorSettings..ctor(SphereSettings settings)
   at SphereStudio.Global.EditSettings(IDEForm parent)
   at SphereStudio.IDEForm.OpenEditorSettings(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
(omitted unless you need them)


I can just click "Continue" and SpheStu won't crash, but it obviously won't open the settings either.
The Game Settings and New Project menu options do work.

Now here comes the biggest issue!

(http://i.imgur.com/uzvOFB0.png) (http://i.imgur.com/11Da6dw.png)

Once I've opened a project (which works without a hitch), I can't open any files! None whatsoever!
The New File and Open File icons in the toolbar don't work either. When I try to create a new file using the context menu instead, I get this:

(http://i.imgur.com/VnoICod.png)

Finally, Open Game Directory and the context menu item Open In Explorer do absolutely nothing. I expected Wine Explorer to open.

So it's almost functional on Wine. Much better than before, no crashes or graphical glitches or anything, just things that silently refuse to work now.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 04, 2015, 09:54:58 am
Looks like it's not loading the plugins for some reason.

As for the hex editor, I was going to propose it as an official plugin only because the current default is to open unrecognized files in the script editor, which is dangerous if a user opens a binary file and accidentally hits save (even if no explicit edits are made--which I believe is why I removed the wildcard from the script plugin originally).  My hex plugin opens read-only by default for this very reason.

It's up to you, but keep in mind the current approach is a disaster waiting to happen. :P

Edit: There's also the issue of the WeifenLuo DockPanel dependency.  Unfortunately neither of us ever fixed that issue, and I don't want to release an external plugin with an explicit dependency on it, since if you ever decide to use a different docking library or a DockPanel update itself includes breaking changes, the plugin will break.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 04, 2015, 10:15:04 am

Looks super neat! I was wondering if you could highlight things in the Sphere files (like headers, image data etc.) with special colors, and indicate in the status bar what the selected value exactly is. Heck, could even go as far as popping up a little image if you selected graphics data inside one of the Sphere files.


That would be very neat, but that's a job for another plugin, I think.  This is basically just meant to fill the role of a default binary file editor, nothing super-fancy.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on April 04, 2015, 05:49:58 pm

As for the hex editor, I was going to propose it as an official plugin only because the current default is to open unrecognized files in the script editor, which is dangerous if a user opens a binary file and accidentally hits save (even if no explicit edits are made--which I believe is why I removed the wildcard from the script plugin originally).  My hex plugin opens read-only by default for this very reason.


Yeah, but I'm unsure on how to handle other filetypes.

I think what should happen next for the editor is to have plugins interact with a sphere-studio file associations section in the settings menu. A plugin registers the filetype to Sphere (and automatically links the defaults) and then you can go into that associations menu and move filetypes around between plugins. Plugins with wildcards get free reign over all filetypes you give them.

I'll comp it up, give it a spin and see how it goes.

Then we won't need the hex editor as a default with Sphere Studio. If you install it, you can go into the file associations settings tab and move associations over to it at your own discretion.

@DaVince:

Manually open the editor.ini and add/replace this key-value pair:
Code: (txt) [Select]

plugins=FontEditPlugin,ImageEditPlugin,MapEditPlugin,ScriptEditPlugin,SoundTestPlugin,SpritesetEditPlugin,TaskListPlugin,WindowstyleEditPlugin
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 04, 2015, 05:58:14 pm
No problem, I made a separate branch for hex editor development, so it'll be easy to split it off without causing merge issues.  I do have to do something about that Weifen Luo dependency though...
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on April 04, 2015, 06:24:17 pm
I'm solving the problem of plugins requiring Weifen Luo right now. I'm creating a descriptor shim, that offloads the dependency to a descriptor. I then use this descriptor editor-side to do work. That means plugins no longer have to worry how their controls get docked. They just tell the editor what and how to do it.

It was bad design of me to give the power of the weifen luo forms to each plugin. I should have done this early on. :(

Edit:
1. I'm rewriting the script auto header tool to take "auto-fields".
2. I'm also moving presets to the presets folder rather than the root.
3. I'm also adding weifen luo as a sole dependency to the editor as a NuGet package rather than as a binary with the source (and removing it from all existing plugins).

When I'm done I'm bumping this to v1.2.0 and removing the last digit from the versioning. I hate MS's versioning structure, the 3-group is perfect for small open source projects.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 04, 2015, 06:45:55 pm

When I'm done I'm bumping this to v1.2.0 and removing the last digit from the versioning. I hate MS's versioning structure, the 3-group is perfect for small open source projects.


Agreed, semantic versioning with three components is easier to understand than using all four elements.  For minisphere, I reserve the fourth number as the "build number"--which is really just the ordinal of the Git commit it was built against. :-)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on April 04, 2015, 07:35:00 pm
Ah man it was a lot of work! So not only did I need to create a descriptor shim, but I had to do a lot of other crap just to get other things to work right like setting the name of the tab text, or updating the style on script editors.

See, when I added WeifenLuo as a required dependency, I kinda gave the plugin creator full free reign over their DockContent. That means peaking at other dock contents too and other weird things that should not be allowed. I must say, adding restrictions requires writing lots more code than giving full access. <sigh>.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 04, 2015, 07:41:17 pm
Yes, now you see that encapsulation is hard.  It's the biggest thing that turns me off of OOP, and why I prefer C over anything else (save for JS, which is awesome)--not having classes means I'm not pressured into trying to encapsulate out of the gate--I can put it off and not have to worry about breaking everything horribly when I do decide to change, since things can more easily be phased in.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 06, 2015, 11:37:39 am
I guess I'll hold off on further development of the hex editor plugin until you finish your changes, since I imagine this is going to affect the plugin manager API in a major way.

My name is Mr. Wilson and I'm here to say
I'm gonna smack your ass in a major way
What are you doing in my basement? Get outta here!
GET OUTTA HERE!!!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 15, 2015, 03:20:38 pm
Does there exist a method in .NET to find out if the OS is 64-bit capable?  This way we could have it try to run engine64.exe if the machine is 64-bit.  Either that or allow other filenames than engine.exe, since currently even if you select a different executable it automatically changes the filename to engine.exe.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on April 15, 2015, 08:05:20 pm

Does there exist a method in .NET to find out if the OS is 64-bit capable?  This way we could have it try to run engine64.exe if the machine is 64-bit.  Either that or allow other filenames than engine.exe, since currently even if you select a different executable it automatically changes the filename to engine.exe.


No method, but I use this hack in SphereStudio:

Code: (csharp) [Select]

(IntPtr.Size == 4) ? "x86" : "x64"
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on April 15, 2015, 11:42:24 pm
Couldn't you just check if engine64.exe exists and run it if it does, otherwise just run engine.exe?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on April 16, 2015, 12:30:42 am
Oh, I see you want to detect if other engines can run in a 64bit version of windows? I'm not sure there. But as FJ said we can create a name scheme or I can simply add a new field and you can choose the 64bit version of the engine.

I might do that... But then there is a default engine (32bit version). I guess I can also make it choose a default engine at startup. Ugh, so many ways to handle it!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on April 16, 2015, 01:12:16 am
Don't worry guys, I already did it. ;)  I used FJ's method, it just tries to run engine64 first.  If Process.Start throws an exception (meaning either engine64.exe doesn't exist or the machine isn't capable), it catches it and runs the 32-bit engine instead.

There's a separate text field in the Paths tab now for the 64-bit engine path.  Like with config.exe, it will be filled in automatically if engine64.exe exists.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: casiotone on April 16, 2015, 05:08:59 am
System.Environment.Is64BitOperatingSystem was added in .NET 4.0: https://msdn.microsoft.com/en-us/library/system.environment.is64bitoperatingsystem(VS.100).aspx
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on April 16, 2015, 10:03:06 am

System.Environment.Is64BitOperatingSystem was added in .NET 4.0: https://msdn.microsoft.com/en-us/library/system.environment.is64bitoperatingsystem(VS.100).aspx


Oh, ha, I didn't realize that, thanks!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on May 29, 2015, 02:23:36 pm
I've discovered an problem with the version on Dropbox.

* Create a new spriteset
* Add a new image
* Select it for one of the frames
* Delete the image

You get an OOB warning dialog, and more importantly you can't seem to recover the spriteset. It just has a red X/image missing icon on the frame until you close the sprite editor.

Not updating the image indices/references when an image is deleted? =)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on May 29, 2015, 02:27:42 pm
Hm, I can't seem to reproduce this with the latest build from GitHub.  It replaces the frame with a valid image (specifically the first one).  Maybe it's been fixed since then...

@Radnen: I sent another PR for the 64-bit engine support, this time I did it on top of your changes so there should be no ugly merge conflicts. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on May 31, 2015, 09:47:51 am
Feature request: Ability to create folders at top-level directly in the IDE.  Because currently, a right-click on the project node only gives you global options (Game settings, Editor settings, Open in Explorer).  I'd do it myself, but I hate working with GUI code if I can avoid it. :P
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on May 31, 2015, 06:30:38 pm
Added, and your changes merged in well enough.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on May 31, 2015, 06:32:42 pm
That was quick!  Now I'm working on updating IrrKlang to 1.5.  They have a 64-bit build now!  Too bad it's not in NuGet...
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on May 31, 2015, 06:41:57 pm
Part of the dependency reorganization was to try and utilize NuGet better so there's less stuff to download/require for any future code editors. And to possibly aid in plugin creation, I mean I removed the strict dependency from Weifen Luo. This also means, going forward, we don't have to use the dockform suite if a better alternative shows up. The plugin's don't care, just the editor needs the overhaul and a remapping from the plugin dock styles wrapper to the actual dock styles.

I want to do so much to this editor, but I've just been busy with work and playing awesome games like the Witcher III. And watching tons of TV shows and movies to get caught up on. And I've even been taking the time to work on a novel, adding programming to that is a bit too much for a single week. :P
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on May 31, 2015, 06:55:13 pm
Okay, that idea isn't going to work (updating IrrKlang).  I can't figure out a way to include both the 32-bit and 64-bit DLLs in the same project and get VS to automatically reference the right one when compiling.  In a C/C++ project this is easy, just change the library path, but the .NET languages use the braindead References system instead.  The only workaround I can think of is to create separate project files for the 64-bit build, but with all the plugins that would be a mess.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on May 31, 2015, 07:18:19 pm

Okay, that idea isn't going to work (updating IrrKlang).  I can't figure out a way to include both the 32-bit and 64-bit DLLs in the same project and get VS to automatically reference the right one when compiling.  In a C/C++ project this is easy, just change the library path, but the .NET languages use the braindead References system instead.  The only workaround I can think of is to create separate project files for the 64-bit build, but with all the plugins that would be a mess.


I haven't used VS > 2013, and never for managed builds, but...

Couldn't you have single projects for each plugin, then two solutions for the editor, one for 32-bits and one for 64-bits, each sharing the projects for the plugins? It's kind of inverting how projects/solutions are supposed to be used, but if it works.

I'm also curious, how important is 32-bit for this project? I'm not saying 32-bit is bad or anything, just wondering.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on May 31, 2015, 07:36:47 pm
The problem is assembly references are tracked per-project (not per configuration) and VS only lets you add one reference with a given name.  If you then try to compile for a architecture not matching that one reference, you get errors.  Making a second solution isn't enough--you need separate .csproj files as well.  On the plus side, it's only the one plugin (sound picker) that would need this treatment, but I don't feel like being the one responsible for making a mess. :P

As for that last question, if it were me I would probably opt to go 64-bit only for the editor.  But it's not my project, so I can't make that decision myself.  I'm only an elected official a contributing developer after all!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on May 31, 2015, 09:28:06 pm
I wouldn't mind going 64 bit but there are libraries that don't support it. I'm not sure which, but perhaps it was the dock suite? I know scintilla has the same issue with 64 vs 32 bit build, but I think for that one AFAIK you just include the base 64/32 bit DLL and the linked/referenced one I think is set as multi-target. In fact, does the multi-target build option make things worse or do you still run into the issues?

I'm also surprised you can';t set different references per build type.

I choose 32bit since it was the most compatible against most computers.

Edit:
I looked into it and people are saying you either hack it into the .csproj or you simply create multiple projects. But doesn't VS allow you to create a shallow clone of the project? I know I did this when I was playing around with XNA to target the PC or Xbox. The Xbox project was basically a shallow copy of the main project. If I modified the main code it'll use the new version, so nothing is copied twice. All it did was use a new reference list and build architecture, and XNA API mode was set to a compatible version just for Xbox/Devices. But the code was the same. If I wanted xbox specific code I'd use #if directives.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on June 01, 2015, 02:53:01 am
Yeah, a project file just references existing source files, that shouldn't be a problem.  When I get some free time I'll see about setting everything up for a 64-bit build.  I think all your dependencies are 64-bit capable, the only outlier to my knowledge is irrKlang (which as previously mentioned has been updated).  I at least remember being able to make a working x64 build of Sphere Studio a while ago, it just didn't have sound.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on June 01, 2015, 05:05:07 pm
Yeah I remember making 64bit builds a while back, so I guess it was possible. I guess it was Irrklang that was the thorn. Are you free to create new branches? If so, create a branch with the changes and I'll review it and if all checks out, it'll take over as the new solution file.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on June 16, 2015, 12:00:25 pm

Yeah I remember making 64bit builds a while back, so I guess it was possible. I guess it was Irrklang that was the thorn. Are you free to create new branches? If so, create a branch with the changes and I'll review it and if all checks out, it'll take over as the new solution file.


Oh, I was supposed to be doing this wasn't I?  I'll get around to it, I kind of got sidetracked implementing SPK support in minisphere. ;)

Which reminds me, I want to make an SPK packer for Sphere Studio, but I don't think plugins can access the project tree?  So it would have to go in the main editor instead of as a plugin I think...
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on June 16, 2015, 04:11:27 pm
For now you can create a package project under the main navigation menu. I think when you create plugins, you can register them under the menu with dots like so: 'project.package' and the project menu will have the item package, for example. But I see an issue here. Sometimes you might want it to say 'Package...' with 3 dots to indicate a function w/ a popup dialog, in that case there's nothing you can do.

I might change that behavior though, to take the '/' parameter. I think packaging shouldn't be a project tree thing, because it's most likely only going to be a root node thing, unless you want the possibility to have packagable projects in sub-folders!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on June 16, 2015, 04:18:02 pm
Okay, I think I was ambiguous with that comment.  What I meant was, is there a way for a plugin to access the contents of the project tree (so it can know which files to package)?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on June 16, 2015, 04:19:34 pm
Sometimes you might want it to say 'Package...' with 3 dots to indicate a function w/ a popup dialog, in that case there's nothing you can do.


Could you use the actual unicode ellipses character?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on June 16, 2015, 08:03:02 pm
@Lord English: Ah, I see I thought you meant to append functionality to the project tree. What you want is a method to see the file contents. I'll look into an API call to get back the currently loaded game settings file.

@Jest: While that's possible, most Windows apps just use '...' without the ellipsis character. Almost never heard of it being used outside of word processing.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on June 18, 2015, 10:07:56 pm
@Lord English: You could use this in your plugin and resolve the file paths for packaging:
Code: (javascript) [Select]

PluginManager.IDE.CurrentGame.RootPath
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on June 18, 2015, 10:11:34 pm
Ah, thanks for the tip.  Do you think we should include an SPK plugin out of the box?  I know you want to keep the number of default plugins down, but unlike the hex editor thing I made a while back, this seems like basic functionality for a Sphere editor (the default editor has it).
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on June 18, 2015, 10:25:54 pm
Sure, add it in!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on June 19, 2015, 03:01:21 pm

Sure, add it in!


Okay, that was relatively painless.  Check your pull requests. :)

edit: and after I go through all the trouble to pull in zlib through NuGet, it turns out there's already zlib-based deflate functionality in the .NET Framework.  Go figure. :P
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on June 29, 2015, 01:40:35 pm
Haha, I see you pulled in my changes already.  That's good, now I can see about making this compile properly for 64-bit. :)

edit: I ended up replacing IrrKlang with NAudio, which is available on NuGet:
https://www.nuget.org/packages/NAudio/

So this way I don't have to create a separate project file, updates are painless and all of your dependencies are NuGet now. :)  and it's also open source (Ms-PL specifically) whereas IrrKlang is free for non-commercial but proprietary.

I just want to test for bugs first and then I'll put up another PR when it's ready.

edit 2: Done making changes.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 03, 2015, 03:13:01 am
@Radnen:
Because I haven't said this and I think it needs to be said: Let me just congratulate you for your work on Sphere Studio.  Now that I've gotten most of the lingering bugs out ;), I see now that it's a very well-designed editor and is quite fun to hack on. :D. The codebase is very clean too (although in my experience it's hard to write messy code in C#), which helps.  A bit rough around the edges, but clean.

So yeah, great job. ;D

I'm done with the most recent batch of changes, by the way.  I wonder... Would it be easier if you add me as a collaborator and skip the pull requests?  It's fine if you don't want to, though.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 03, 2015, 12:32:15 pm
Lord English: you are now a collaborator on the project.

I actually wanted you to be a collaborator earlier on, but you insisted pull requests were still okay with you. :P Anyways, enjoy the privilege just don't do crazy edits to the code (like replacing a plugin instead of making a new one, unless the core of that plugin needed an upgrade). I trust you enough to push the project in positive ways.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 03, 2015, 01:03:37 pm
Re: Pull requests: Keep in mind that was before I had an engine which included the editor as part of the package. ;)  I'm assuming I will be doing more active development on the editor now, so I don't want my fork to end up getting too far out of sync with the official project.

I'll try not to make major changes directly on master, though--big stuff if needed will be done on a separate branch.  As it should be.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: DaVince on July 03, 2015, 03:42:51 pm
Two active developers on this editor = awesome. Which leads me to something that's going to make me sound like a broken record... but how feasible is it to get this compiling on Mono at this point so this whole thing can become cross-platform? I'm really eager to use this on Linux, y'know! :P
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 03, 2015, 03:50:11 pm
Can Mono be installed on Windows alongside the .NET Framework?  If so I could do some testing of my own.  Not sure how good .NET 4 support is in Mono...
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: DaVince on July 03, 2015, 04:25:01 pm
I do believe you can do that, yes. As for .NET support, this (http://www.mono-project.com/docs/about-mono/dotnet-integration/) is currently happening. I also know for a fact that there is winforms support already, at the very least.

Some of the libraries probably need an update or some changes to work.

I'm always prepared to run the program through Mono on Linux and report the results. (I'm getting a TargetInvocationException right now, could provide details, but maybe you'll get the same messages once you try Mono on Windows.)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 03, 2015, 09:09:29 pm
Lord English: I hate what you've done to the editor.

You've made it awesome. I hate awesome things... not! It's amazing! The configuration selection feels like it's from Visual Studio - a nice touch. Later, I'm going to update the system for managing configurations since it's a little clunky which one you are editing and it's not easy to overwrite an old config with a new version (or straight-forward in any case).

I'm also still not done with the 'script' header section. I'm trying to figure out a good place to put it. Ultimately it must be tied to the currently active script plugin (which it's not). So, I'm going to rework the whole concept. I want to make a script header system that uses the game.sgm file and the current script plugin to provide consistent and clean script headers.

I'd also want to go through and update the editors from fonts to windowstyles. They are still a bit clunky for being from the version 1.0 era.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 03, 2015, 09:17:00 pm
Haha, for a second there I was worried you were serious. :P  Then again, that's why version control exists. ;). But yeah, I was going for a Visual Studio feel for the configuration selection.  I felt the x86/x64 selector was needed, since it's good to test a game on both platforms.

Have you tried the new minisphere installer perchance?  It preconfigures the editor for you with presets for minisphere, and selects Console by default.  That should go a long way towards making Sphere more accessible to newbies.

Since you're going to be making changes now, I guess I'll make a branch so I can work on some changes of my own.  Unless that was a hint...? :)

edit: Tell you what, I'll work on the GUI refresh on a separate branch (gui-overhaul) and merge it in when it's done.  This way it minimizes potential merge issues in case you make changes in the meantime.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 04, 2015, 02:12:26 am
@Radnen:
Since you hate awesome things so much, here:
https://github.com/Radnen/spherestudio/commit/8326b31d246b719851ad7abb5daec10187e485ef

Remember how I was working on a hex editor plugin a while back?  Well, I ended up stopping because the editor didn't have a way for multiple plugins to register a wildcard (*) handler without clobbering one another.  Now it does. :D

It always surprises me how little of the internal plumbing I have to change to support features like this.  The plugin manager was well designed.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 06, 2015, 02:19:05 pm
So guys, some good stuff is cooking up for this editor. I'm going to set up milestones toward a version 2.0 of this editor. At the end, it'll have full project management features.

You'll have a .ssuser file which contains the settings for your currently opened files and other local settings. This file does not get sent to a a project's repository.

Then you'll have a .ssproj file which is like a .vcproj file which contains everything a collaborator needs to build the project, even NuGet-like packages we discussed about. When you build the project with my editor it'll seek out and download nay linked dependencies. No more coping threads.js or link.js for your projects. :)

Speaking of building a project, Sphere Studio 2.0 will have a project pipeline. Everything will be written to a /dist folder. The game.sgm no longer is distributed with the project source anymore. Sphere Studio will generate that file on build. The /dist folder does not get sent to the repository. This build system will eventually support file processors like minification, sprite sheeting, font generation, etc. In this way the stuff you do distribute is perhaps of a lighter weight than the source.

The tandem of .ssuser and .ssproj files will make it easy to collaborate with others on a project.

Another module I'd love to add by 2.0 is a git integration. It's most likely going to be bare bones and require you to have git-scm.exe installed on your computer and in your PATH (like tortoise git and others) (it'll have push/pull and branch switching and merging and ability to set user info). But that's still some ways off.

I'd love to wait and surprise you all, but it is an open source project so some of you would see it all coming anyways. :P
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 06, 2015, 05:48:55 pm
I think what we should do for now is finalize the preset and settings handling to get the bugs out of that, so 1.2.0 can be released.  Then start on the 2.0 changes.

Oh, and also I still have to do some testing on Mono. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 06, 2015, 06:06:51 pm
Well I went ahead with user settings saving anyways. I figured it can be fairly standalone since it's not crucial to the whole pipeline concept, plus I really wanted to store currently opened files.

It's on a branch called user-settings.

This was actually extremely difficult to program, because WeifenLuo DockForms is a crappy, very terrible interface. I kept running into stupid issues with it when it comes to ActiveDocument, which should never happen. Currently if you close a project with no tabs open, it must open the start page even if you never wanted it to show. You can close it afterwards, regaining an empty screen, but you can't load it as an empty screen. This to me makes no sense.

It was also hard to figure out when to save the opened documents. Too late and they are disposed, and there was never too soon. It turned out I aggressively disposed the content panes too soon. Once I figured that out, I was able to retrieve the opened filenames. There is still some wonkiness with the last human-viewed file, but I think many quirks were ironed out.

Also closing documents when switching projects was a pain because at that point I needed to add a 'are you sure?' dialog to any unsaved files. I didn't want the system to store opened documents of another project into your current .ssuser project file. So I had to make sure the files were all closed - definitely closed - before loading another project.

The organization is terrible, however. Next step is to clean it up, which is tedious, time consuming and mind-numbing.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on July 06, 2015, 06:12:58 pm
This was actually extremely difficult to program, because WeifenLuo DockForms is a crappy, very terrible interface.


WeifenLuo DockForms was coincidentally the showstopper for me every time I tried to get the editor working under Mono.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: DaVince on July 06, 2015, 06:26:09 pm
Nice ideas. This sounds super excellent and like it'd bring Sphere back into the modern world of game development.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 06, 2015, 06:29:02 pm
@Radnen: I like refactoring, I could take a stab at the cleanup. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 06, 2015, 07:05:11 pm
I have now merged user-settings into master. If you want to do the refactoring, you can. What I want to see is a proper interface for handling opened projects and user settings. Basically, I want to reduce the # of lines in the IDEForm.cs file by offloading some of the management stuff to dedicated classes than trying to do it all at once there. Though I will say it can get a bit convoluted.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 07, 2015, 01:28:32 pm
So I got Mono set up on my main development machine, and I see that TargetInvocationException mentioned by DaVince, which is in reality a boxed ArgumentException thrown, ultimately, by the System.Drawing.Icon class.

The stack trace is interesting: I was about to trace the crash back to this line:
Code: (csharp) [Select]
this.Icon = ((System.Drawing.Icon)(resources.GetObject("$this.Icon")));


Apparently Mono doesn't like the Sphere Studio icon for some reason...

Here is the bit in the Mono source itself that's throwing the exception:
Code: (csharp) [Select]
//Determine the AND array size
numBytesPerLine = (int)((((bih.biWidth) + 31) & ~31) >> 3);
int andSize = numBytesPerLine * iconHeight;
iidata.iconAND = new byte [andSize];
nread = bihReader.Read (iidata.iconAND, 0, andSize);
if (nread != andSize) {
string msg = Locale.GetText ("{0} data length expected {1}, read {2}", "AND", andSize, nread);
throw new ArgumentException (msg, "stream");
}


edit: Okay, I got it past that by re-rasterizing the SVG and making a new .ico (768x768 Win10 icon, yay!).  I'm guessing Mono got tripped up by the 64x64 image in the original .ico file.  However, now I get a different exception, matching what FJ said above: It crashes with an ArgumentException from System.Drawing whose root cause traces back to a WeifenLuo call made in IDEForm.CloseAllDocuments().  Having done a bit of research, it appears there might be no way around this, at least for the time being--DockForms uses PInvoke internally to call into the Win32 API.

edit 2: Weird, apparently as of DockPanel 2.6, Mono should be fully supported (drag and drop would be disabled there since that's where all the PInvokes are used), yet it's clearly not working here.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: DaVince on July 07, 2015, 03:42:36 pm
Apparently, "the incompatible features are automatically disabled at runtime", according to a comment in the top answer (http://stackoverflow.com/questions/8558187/how-can-i-use-dockpanel-in-linux-mono-with-all-its-features). I guess SpheStu might be using an incompatible feature?

I really appreciate that you're checking it out on Mono, by the way. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 08, 2015, 12:11:09 pm
No problem. :)

In other news, look what I just added to the editor!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 09, 2015, 11:58:51 am
@Radnen: I'm working on the new Document framework now.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 09, 2015, 06:04:56 pm

@Radnen: I'm working on the new Document framework now.


Is that part of your refactorization?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 09, 2015, 06:11:27 pm
Yes.  Trying to generalize the docking stuff to make t easier on plugin writers and also make the core cleaner.  See the GitHub issue about it.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 18, 2015, 01:19:52 am
@Radnen: I got bored and implemented .ssproj support for you. ;)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 18, 2015, 02:08:55 am
Wow, thanks! Sorry if I'm not working on my project all that much. I've been playing the game ARK and relaxing from work. My weekends have all been full and I've had little time to crack open a code editor to write the code.

You either don't have a day job or you must have loads of free time or you really love programming. Whatever it is, I thank you for continuing the development of the editor.

Perhaps this Sunday or Saturday night I'll take a crack at the 'pipeline' and possibly introduce JS minification, and scriptable processors (which will no doubt take a JS engine, likely Jurassic for it's C# flexibility and that I know it the most).
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 18, 2015, 02:16:05 am
I work part time so I do have more free time than most, but yeah, I love programming, it's fun. :)

I ended up refactoring the whole settings system in the process, so you may have to reacclimate a bit.  Overall the encapsulation is much better now.  Oh, and I implemented a proper INI writer, sections and all.

I can also confirm that the editor works great on Windows 10.  :D
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 18, 2015, 04:43:42 pm

I ended up refactoring the whole settings system in the process, so you may have to reacclimate a bit.  Overall the encapsulation is much better now.  Oh, and I implemented a proper INI writer, sections and all.


Don't worry, I've been reading through all the code commits and such. ;)

I was surprised when I saw little to no .INI support out of the gate with .NET. The project never needed a full-on ini solution anyways, but since you wrote one, hey more power to it!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 18, 2015, 04:52:01 pm
I think they were trying to get everyone to go to XML, but really that's just too complex for something simple like saving settings.  Simple key=value pairs with optional categories are perfect for that.  Honestly I think the INI format was one of the best things MS ever came up with, certainly better for its intended use than the bloated beast they call the registry.  But I digress. :P

That said, I could see the .ssproj file being XML though.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on July 18, 2015, 05:00:10 pm
I was thinking XML because it has a better sense of scoping. INI's are flat. But then again, I'm not sure SphereStudio is at a stage where me have multiple .ssproj files like Visual Studio. Most people tend to make one game at a time per 'solution'. I think it's good to keep that for now.

Oh, I also was thinking about making new spriteset, image, tileset, map and windowstyle editors. I think the map editor is still very power since it had 3 total rewrites by now, it's the other editors that need more attention.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on July 18, 2015, 05:36:54 pm
I would think that for a JS-centric system like this, JSON would be a better choice than XML.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on July 18, 2015, 05:45:55 pm
Hm, that might be a good idea.  It would allow easy access to the project file from build scripts and the like.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on July 18, 2015, 07:12:12 pm
It would also mean that by integrating a JS engine (like you mentioned) you would automatically get a reader, too.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 09, 2015, 07:08:13 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 09, 2015, 07:20:14 pm
Personally I hate WPF and avoid it like the plague.  Every time I've tried it I end up giving up in disgust.  WinForms I feel more closely models how a GUI app actually works, whereas WPF and XAML seem designed to work more like how HTML/CSS do.  For the web this kind of thing is fine because much content is static and therefore there is usually more data and layout than code.  In a GUI the situation is usually reversed so using that workflow gets awkward.

Honestly, I'm mostly indifferent to this.  Sphere Studio not being able to run under Mono is an issue, though...  I guess experiment and see what you come up, and go from there.  Don't make the mistake of committing to anything early on.  Remember that minisphere started as an experiment too. ;)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 09, 2015, 08:39:39 pm

Personally I hate WPF and avoid it like the plague.  Every time I've tried it I end up giving up in disgust.  WinForms I feel more closely models how a GUI app actually works.


True there, in fact I can *build* a GUI app three times faster in WinForms. But many businesses (like the one I work at) are not, for some odd reason, looking at people who build WinForms apps anymore.

But yes, WPF workflow is like HTML/CSS, but I'd pout the latter over the former any day of the week, hence Brackets being awesome.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: N E O on August 11, 2015, 10:13:22 pm
Re opening Sphere formats in a brackets-like editor - Can we reuse the JS-based loading we've already written (i.e. all the web-based format loaders and casiotone's and Flying Jester's desktop JS loaders) to make this happen, or would we need to write brand new format loaders?

Re a brackets-like editor - It's been a long while since I've even looked at brackets; what would be the advantages of basing a Sphere IDE off of it rather than, say, GitHub Atom?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 12, 2015, 12:44:47 am

Re opening Sphere formats in a brackets-like editor - Can we reuse the JS-based loading we've already written (i.e. all the web-based format loaders and casiotone's and Flying Jester's desktop JS loaders) to make this happen, or would we need to write brand new format loaders?


Yes definitely possible. But there are actual file I/O API's that make it a lot easier than before. But in theory all web based approaches would work too.


Re a brackets-like editor - It's been a long while since I've even looked at brackets; what would be the advantages of basing a Sphere IDE off of it rather than, say, GitHub Atom?


http://electron.atom.io/

That would be the solution. To me Brackets and Atom are very similar in design and approach, there are no advantages one or the other. The exception being, Atom has this framework called Electron and it seems to do the trick. I'd create such a Sphere Editor with that.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 02:20:15 pm
I don't know if anyone else has noticed this, but when I download the zip file in the OP in Firefox, it blocks it because it thinks it's malware. I can right click and have it unblock it, but I shouldn't have to do that in first place. Any ideas?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 02:25:05 pm
This is in Windows 10
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 02:28:36 pm
Looks like a false positive on Mozilla's end (or Google's, since it's their blacklist being used).  There used to be a way to disable the download scanning, I don't remember it now or if it even still works.  Either way, not a lot you can do other than unblocking it after download.

I love the prompt on attempt to unblock:
This file contains a virus or other malware that will harm your computer.

You can search for an alternate download source or try to download the file again later


Not "this file may contain a virus", or "likely contains", no.  "This file contains a virus".  False positives are a well-known fact of life with malware scanning, and yet Firefox is acting like it's so sure of itself.  The ticks me off for some reason.  You're not the only one experiencing it:
https://support.mozilla.org/en-US/questions/1049744
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 02:34:09 pm
Yeah, I thought that was kind of funny. I was just curious why it was throwing this with Radnen's editor

also, the editor won't start now. I tried to run it from explorer and got no response. I tried to run it from the command line and didn't get any output, so I ran it in Cygwin and got this

Code: [Select]

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Users\Joshua\Dropbox\Programming\Sphere\Plugins\FontEditPlugin.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
   --- End of inner exception stack trace ---
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at SphereStudio.Global.EvalPlugins()
   at SphereStudio.IDEForm..ctor()
   at SphereStudio.Program.Main(String[] args)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 02:35:50 pm
Windows sandboxing.  The OS recognizes that the files came from the internet and won't run the editor with full trust, preventing plugins from loading.  Easiest way around it is to zip everything up into a new zip file and unzip to remove the flag.  Alternatively, you could just install the minisphere GDK and get Sphere Studio installed that way.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 02:40:23 pm
>Lord English Special color scheme
http://i1.kym-cdn.com/entries/icons/original/000/007/839/f5753870a40ccef114a6cb88e7f48531.jpg (http://i1.kym-cdn.com/entries/icons/original/000/007/839/f5753870a40ccef114a6cb88e7f48531.jpg)

But yeah, I rezipped and unzipped it, and that fixed it.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 02:42:32 pm
Yeah, that color scheme didn't come out nearly as well as I envisioned it.  I should probably remove it. :P
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 02:43:54 pm
so is miniSphere the most feature-complete engine?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 02:44:42 pm
Yes, and it even has a debugger now. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 02:46:24 pm
Damn. Like a console?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 02:48:42 pm
Well, more like MSVC.  It's built into the version of Sphere Studio included with the minisphere 1.7 GDK.  You can set breakpoints, step through the JS source, view variables and even inject code at runtime.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 03:15:38 pm
Alright, I'm having an issue with setting my games folder. in my Dropbox older, I have Dropbox\Programming\Sphere
Inside the Sphere folder, there is games, minisphere GDK, and Sphere 1.6
I want to set the games folder as the project folder, but when I click save and/or apply, it drops the from the list. The games folder has the usual game folders with the usual game folder contents.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 03:26:51 pm
Whoops, that would be a regression.  I just fixed it in git, for now you may be able to work around it by adding a "gamePaths" entry to the Sphere Studio.ini stored in My Documents\Sphere Studio\Settings (paths separated by pipe characters)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 03:35:08 pm
Nope. adding
Code: [Select]

gamePaths=C:\Users\Joshua\Dropbox\Programming\Sphere\games

to Sphere Studio.ini gives this error

Code: [Select]
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
   at SphereStudio.IDE.Project..ctor(String filepath)
   at SphereStudio.IDE.Project.Open(String rootPath)
   at SphereStudio.Components.StartPage.PopulateGameList()
   at SphereStudio.IDEForm..ctor()
   at SphereStudio.Program.Main(String[] args)
Segmentation fault
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 03:37:52 pm
Huh.  That's weird.  Nothing odd in that folder that might be tripping it up?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 03:40:42 pm
http://pastebin.com/QYbWi4zs
Here's an output of ls -R games
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 03:48:31 pm
Looks like a normal Sphere games folder, huh.  Probably something dumb happened with the new project system.  This is the one thing I hate about .NET: the whole thing is based on the EAFP principle ("easier to ask forgiveness than permission") so if anything at all goes wrong it throws exceptions all over the place.

I'll look into it later.  For now you'll have to store your Sphere projects in Documents/Sphere Studio/Projects if you want the editor to find them, sorry. :(
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 08:32:17 pm
Eh, I hate hacky fixes, but if that's currently the only way to get it working, I guess I'll go with that.

Is that what you've been doing? Putting your game folder there?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 08:33:59 pm
That's the default folder by design.  Studio will always look there for projects regardless of what custom paths you have set.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 08:37:53 pm
So now that you have it fixed in the repo, how long will it be before it's released?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 08:41:09 pm
Officially this is Radnen's project, but I'll bundle a fixed version with minisphere 1.7.2 in a day or so.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 14, 2015, 08:45:36 pm
Dammit, putting it in ~\Documents\Sphere Studio\Projects still triggers the error
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 08:47:11 pm
Hm, only thing I can think of is a corrupt game.sgm file...
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 14, 2015, 11:33:59 pm
Okay, I found the bug:

Code: (csharp) [Select]
Match match = regex.Match(file.ReadLine());
string key = match.Success ? match.Groups[1].Value : null;
string value = match.Success ? match.Groups[2].Value : null;
switch (key.ToLower())
{
//...


I was using key without checking whether it was null.  Pretty dumb considering I had a clause two lines above to set it to null if the regex isn't matched...  I'm guessing it ran into a game.sgm file that contained something other than key=value pairs somehow.  Blank lines perhaps... surprising that this didn't show up before.

I know you said you were going to make your own editor, but I'll fix the bug anyway. ;)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 15, 2015, 01:40:29 am
I should update this to like 1.2.0 since so much awesome stuff has been added. But I've been reluctant because the project management system is in a bit of an upheaval now.

Hey, Lord English: in your updated Sphere Studio (with MiniSphere) I see .ssuser and <game>.ssuser which one is correct, because both seem to be used. I was thinking like .gitignore or .makefile or whatever that it was a nameless file (just the extension). What do you think?

Also inside the <game>.ssuser I see these values:
Code: (ini) [Select]

bp_4F230F33=
bp_EEDEA5C4=
viewState_EEDEA5C4=473|473|0
viewState_4F230F33=459|459|1
hideStart=False
openDocuments=
currentDocument=C:\Users\Andrew\Desktop\Sphere 1.6\games\Blockman\scripts\main.js
bp_428E1016=
viewState_428E1016=2507|2507|81


which seem cryptic to me!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus 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.

"viewState_xxxxxxxx" values store the current display state of each document (e.g. for script files, the current line and selection), the hex part is a hash of the filename.  Storing full filenames wasn't really feasible because files are allowed to have equals signs in them, which would confuse the INI parser.

"bp_" are lists of lines with breakpoints for each script file.  Truthfully, these shouldn't be stored as hashes though because the filename can't be recovered from the hash, meaning you have to open it before the saved breakpoints are honored.  I'll think of something better eventually.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 15, 2015, 01:53:56 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.


"viewState_xxxxxxxx" values store the current display state of each document (e.g. for script files, the current line and selection), the hex part is a hash of the filename.  Storing full filenames wasn't really feasible because files are allowed to have equals signs in them, which would confuse the INI parser.


That makes sense, full filenames were indeed a bit much to store. It's elegant too.


"bp_" are lists of lines with breakpoints for each script file.  Truthfully, these shouldn't be stored as hashes though because the filename can't be recovered from the hash, meaning you have to open it before the saved breakpoints are honored.  I'll think of something better eventually.


Ah, cool. Eventually we can save folded lines, but that'll wait until there is a more compact method. For now I guess it's okay.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 15, 2015, 01:57:15 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.


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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 15, 2015, 02:13:34 am
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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 15, 2015, 02:44:49 am
Yay, the game path setting finally works!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 15, 2015, 02:48:50 am
Yeah, I'm not sure what happened with your game directory, apparently one of your game.sgm files made it angry.  :P  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. ;)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 15, 2015, 03:14:20 am
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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: DaVince on August 20, 2015, 09:36:40 am

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)...
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Eggbertx on August 20, 2015, 02:36:02 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 22, 2015, 07:59:41 pm
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:
Quote

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


It's so weird. The paths and args match completely.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 22, 2015, 08:15:14 pm
Huh.  I'll look into it.  It's possible I broke something when I implemented the config manager.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 22, 2015, 09:13:07 pm

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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 22, 2015, 09:51:39 pm
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. ;)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 22, 2015, 10:09:14 pm

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). :o

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

Edit: aand... done!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 22, 2015, 10:50:50 pm
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. :(
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 23, 2015, 02:14:38 am

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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 23, 2015, 03:08:47 am
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);
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 23, 2015, 03:20:30 am
@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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 23, 2015, 11:56:14 am
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!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 23, 2015, 08:03:18 pm
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. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 23, 2015, 08:09:16 pm
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?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on August 23, 2015, 08:35:34 pm

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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 24, 2015, 03:03:05 am
Okay, everything should be in good shape, no release blockers on my end.  I will keep looking out for glitches and crashes, of course. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on August 29, 2015, 12:53:36 am
I just posted minisphere 1.7.6 whose copy of Sphere Studio includes the new Entity view mentioned earlier in the thread. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on September 02, 2015, 12:26:54 am
@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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on September 02, 2015, 03:23:15 am

@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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on September 02, 2015, 03:25:46 am
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. :P. You can see the results of my experiments in the "jurassic" branch.  It went surprisingly well.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on September 02, 2015, 03:35:55 am
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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on September 03, 2015, 12:56:30 pm
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...
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 02, 2015, 05:47:30 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on October 02, 2015, 07:26:24 pm
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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 03, 2015, 03:37:43 am
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.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on October 03, 2015, 10:29:27 pm
I have no time this weekend. I upgraded my computer and it took a whole day out.

I like the fallback approach. It makes it seem more robust if you have no plugins activated.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 04, 2015, 02:20:11 am
As is usually the case for me, what started as a quick integration of Sphere Studio with Cell turned into a massive refactoring project:
https://github.com/Radnen/spherestudio/commits/cell-integration

The plugin system is in the process of a major overhaul.  Plugin modules are no longer limited to a single role, and can in fact serve many.  This is accomplished by having all plugins derive from IPluginMain and then, when they initialize themselves, they can register various roles for themselves, like this:
Code: (csharp) [Select]

cellCompiler = new CellCompiler(conf);
starter = new minisphereStarter(conf);
PluginManager.RegisterPlugin(this, cellCompiler, "Cell");
PluginManager.RegisterPlugin(this, starter, "minisphere");


The great part of this system is that RegisterPlugin() takes a reference to the PluginMain, so cleanup is simple:
Code: (csharp) [Select]

PluginManager.UnregisterPlugins(this);


The other new addition is Starters.  A Starter handles all the details of launching an engine (command line, environment, etc.) so that the IDE doesn't have to care what the details of the engine being used are.  As long as a compatible compiler is used, e.g. Cell for minisphere, everything works seamlessly.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 05, 2015, 02:01:54 am
Here's yet another new thing I'm working on, a Settings Center.  It collects all the configuration windows from various components (including plugins) into one.  In fact, settings pages go through the same plugin API mentioned above.

8)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on October 05, 2015, 02:52:22 am
Yes, that's awesome. It's really needed. I was envisioning a menu like that for a long time. :) +1
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 05, 2015, 03:24:57 am
This particular layout was inspired by the Winamp configuration.  A lot of apps (including Visual Studio) have a similar setup, but the idea of tabbed pages is something I've only ever seen in Winamp, and I really liked it, so I copied that design here.  It gives an additional level of organization that really matters sometimes--you don't get overwhelmed with a bunch of controls at once, but at the same time the sidebar doesn't get so full of sections that you can't quickly find anything (VS is guilty as charged here).
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 05, 2015, 02:01:18 pm
It's done: Everything which is user-configurable is now implemented through the plugin system: engines, compilers, editors.  This means that, with some tweaks to the project system, Sphere Studio could conceivably be used with any kind of game engine.

I left Sphere 1.5 support built in as a default fallback, but even it now goes through the new IStarter interface.

So, breakdown of what's new (note: not yet in master, needs further polishing first):
* Settings Center, collecting IDE and plugin settings in one place
* Builder/compiler support
* Pluggable engines
* "Swiss army knife" plugins - multiple functions in one plugin
* Less bugs!

One of my main goals with this refactoring was to knock down the dichotomy between "plugins" and "core editor stuff".  I think I accomplished that pretty well--plugins feel much more integrated into the experience now.  Plus it makes the codebase easier to maintain--features can easily be moved between different plugins or even into and out of the core at will.  It's awesome.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 06, 2015, 03:02:11 am
Here's a more revealing screenshot, showing as many of the new improvements as I could fit on one screen.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on October 06, 2015, 03:19:40 pm
If you can clean some of your features up, I'll add them to v1.2.0 then update the description to include the new features.

Also, should we package the plugins with the editor or separately? What if we have a starter pack and advanced pack? Like the advanced pack has the debug tools - or are those going strictly with the minisphere bundle?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 06, 2015, 03:32:49 pm
That's part of the reason for the Swiss-army plugins (the other being it was the easiest way to overhaul the system)--I was able to combine the minisphere-specific functions into one plugin.  That said, a standard and advanced package might not be a bad idea.  I don't think we have enough plugins to justify the split at present though...

As for inclusion, I think the basic Sphere format editors should be included with the main download, at least for right now.  We want this to be a complete Sphere 1.5 toolchain out of the box so it can be used as a drop-in replacement for the Vanilla editor.  It might be good to revisit this question later though, for v2.0.

I'm almost done with the overhaul, I just need to finish adding XML comments and then I'll give it a quick review to make sure there are no other implementation changes needed.  My main goal at this stage is to stabilize the plugin API so it doesn't need any further incompatible changes.  Making third-party plugins has been kind of a no-go till now because the public API keeps changing.  If I can get it to where that's no longer needed, that would be ideal.

The new API is going to take some adjusting to, but is a much more robust setup, and we can now add entirely new classes of plugins without breaking the interface for existing ones.

edit: I think it also might be a good idea to switch to semantic versioning:
http://semver.org/

Since we have a public API (for plugins), this makes the most sense.  I technically use SemVer for minisphere, but I'm not very strict about it--I won't usually break compatibility in a patch release, but I do regularly break things in minor versions.  It's actually very difficult to follow religiously (just fixing a bug may sometimes require a breaking change, for example), but useful as a guideline at least.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on October 06, 2015, 08:43:51 pm
Yeah, I'm definitely going to convert over to semantic versioning. I've used it for basically everything else. It was just that when I started this I saw the MS versioning, but I never really used it right, partly because it's so bulky and obtrusive to use and almost require some automation for the minor numbers, which is not something I wanted to manage.

New version for this and all official plugins will be 1.2.0 when these changes are made. I'm holding off until then.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 06, 2015, 09:00:28 pm
The last thing I have to do before merging to master is fix the embedded image and script editor shims, because they are needed for the map plugin but were broken by the plugin API changes.  That should be about another hour or so of work.

I'm quite happy with the results, Sphere Studio feels like a proper development environment now, fully customizable and everything.  The Settings Center is the best thing ever, I was about to add options for the minisphere debugger that had no place to go before this.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 07, 2015, 01:49:26 am
All the changes have been merged.  For cleanliness, I squashed everything down to one commit before pulling it into master.  Feel free to check it out. :)  Also take a look at the minisphere GDK plugin for a good demonstration of using the new plugin API.

To prove the engine independence, I moved the entirety of Sphere 1.x support into a plugin, Sphere Classic.  The IDE doesn't know or care what kind of engine you use now (for the most part, there are a few Sphere specifics still in the project system that can be worked out before v2.0), it's all handled by the plugin.  On that note, it should be much harder now to end up in a situation with no plugins are enabled, because the Configuration Manager will now warn you if no plugin is selected for an essential task before you close the dialog.  And in general the whole IDE is more resilient to missing plugins, which is nice.

As for removed stuff, there's just one thing: The SPK plugin.  Packaging is provided through the compiler plugin now, minisphere supports it via Cell, but I left it out of the Sphere 1.x plugin for now.  It would be easy to re-add it, but it's probably not worth the effort since Cell is compatible with vanilla.

If you make an official release, be sure to exclude the GDK plugin, it's incompatible with minisphere 1.x.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 07, 2015, 05:30:49 pm
I never run out of ideas it seems... I started another project, updating the dock interface to make it possible for the editor to save visibility state of individual panels between sessions.  This new plugin setup I came up with is great for things like this, a lot of improvements that would have required a lot of effort before are now low-hanging fruit.

The IDEForm.cs is still a monstrosity though.  I'm gradually spinning stuff off of it to clean it up, but it's been slow-going.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on October 07, 2015, 08:50:15 pm
Wait.. so you're saying it's no longer a "Sphere" Studio now? :P

I could then create modules for C# SFML and have an environment to create C# games... in C#!
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 07, 2015, 09:19:19 pm

Wait.. so you're saying it's no longer a "Sphere" Studio now? :P

I could then create modules for C# SFML and have an environment to create C# games... in C#!


Pretty much this, yeah.  As long as you're willing to write a compiler and engine plugin for it, at least. ;)  The system is very extensible now.  The only real blocker is that the screen resolution and "startup script file" are still tracked at the project level (for Sphere 1.x anyway, Cell ignores the .ssproj and reads it from the cellscript).  If we could somehow get that dependency out of the core, it would be completely engine-independent.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 08, 2015, 09:50:41 am
For the record, LINQ was an invaluable tool for this overhaul.  I've gotten very good at employing it now, having used your Link extensively throughout Specs.  Despite the various disparate types of plugins, all registered plugins are stored in a single flat List<> and the correct ones are picked out using LINQ and reflection.  It's really quite elegant. :D

One thing I'm debating is whether I should move the Configuration Manager (preset editor) into Settings Center.  Thoughts?

edit: I added a few tips to check plugin settings when an error occurs due to a missing handler.  One thing I noticed came up consistently in testing is users were confused when starting from a fresh install, double-clicking files caused a "can't open this kind of file" error since there are no plugins loaded.  So now the editor points them in the right direction.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 10, 2015, 01:36:27 am
The new plugin system is so powerful that I was able to convert a lot of _internal_ components, like the Start Page and project tree, to use the plugin interface.  Doing so served to clean up the code even more, and also fixed a lot of glitchiness caused by the core components interacting badly with plugins.  Since these components are actually plugins themselves now, just registered internally, they get along much more smoothly this way.

And here's another screenshot, just to show everything is still functional and I didn't break anything ;)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 12, 2015, 12:36:16 am
Okay, I moved the minisphere plugin out of the SphereStudio repo and into minisphere proper.  That's part of the reason I wanted to get the plugin API finalized, so it would be less painful to develop the plugin separate from the IDE.  The other reason is... well, it was just no fun to make plugins before! :P

I also added source for an Inno Setup installer to the repository.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on October 12, 2015, 02:47:04 pm
I was going to look at this this past weeked, but I got caught up in other things (a personal project I'm working on for a paying client). Next weekend I'll take another look. I'm hoping to have a quieter weekend then.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 12, 2015, 02:49:57 pm
No problem, I killed time by fixing bugs and polishing things up.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 15, 2015, 04:07:46 pm
New feature: Toolchain (engine and compiler) can now be set per-project.  So if you have some games using minisphere and some using Sphere 1.x, the IDE will automatically switch to the correct toolchain when opening the project.

SGM import is broken now, though.  I'm considering how to go about fixing it.  Watch the GitHub issue for status:
https://github.com/Radnen/spherestudio/issues/54
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 18, 2015, 02:55:06 am
Okay, SGM import works again, through a new File menu item "Upgrade SGM".  The editor will no longer open SGMs directly anymore because with the new build system and dist/ directory, the extra .sgm files end up cluttering the start page and could even cause you to lose progress if you accidentally edit a compiled dist instead of the original project... :P

I also added saving dock pane visibility.  Now if you close a panel, it will still be closed after you restart the editor.  AutoHide state is remembered, also.

Finally, I changed the way engines are handled.  Now you can switch between all installed engines and test games with any of them at will.  It's basically an evolution of what you could already do with presets in 1.1.7.0, but wired directly into the plugin manager so you no longer need to manually make a preset for each engine.  As long as the plugin for an engine is installed, you can select it from the toolbar.

Let me also just reiterate for the record just how horrid the Weifen Luo API is. >:(  At least it's more maintainable now, all the dock handling is confined to a single module (DockManager.cs) rather than all over the place like it was before.  And plugins don't have to care about its idiosyncrasies at all--just implement IDockPane (a mere 4 properties!), pass it into PluginManager.Register() and call it a day.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 18, 2015, 10:41:29 am
On a minor sidenote re: the Weifen Luo controls, I think this is the most awesome piece of code I've ever written:

Code: (csharp) [Select]

bool autoHide = Core.Settings.AutoHidePanes.Contains(name);
DockState state = plugin.DockHint == DockHint.Float ? DockState.Float
    : plugin.DockHint == DockHint.Left ? (autoHide ? DockState.DockLeftAutoHide : DockState.DockLeft)
    : plugin.DockHint == DockHint.Right ? (autoHide ? DockState.DockRightAutoHide : DockState.DockRight)
    : plugin.DockHint == DockHint.Top ? (autoHide ? DockState.DockTopAutoHide : DockState.DockTop)
    : plugin.DockHint == DockHint.Bottom ? (autoHide ? DockState.DockBottomAutoHide : DockState.DockBottom)
    : DockState.Float;  // stacked and nested ternary = awesome


Funny thing is, I used to avoid ternary conditionals like the plague, thinking they made the code harder to read.  But had the above been written as a traditional if/else tower... *shudder* (I still would have found a way to make it as compact as possible though ;) ) Nowadays I use them all over the place.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Radnen on October 18, 2015, 12:09:30 pm
It looks to me that the code maps between the generic dock parameters and Weifen Luo dock parameters. I generally dislike humongous ternary operations because if nested too much they get nearly impossible to follow. But for this one you managed to lay it it out very neatly.

Another solution would be to use some kind of bit mask or some array map() function.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 18, 2015, 12:29:23 pm
If you peruse the minisphere codebase you'll see I use a lot of stacked ternaries.  I don't generally nest them like I did here though.  The biggest challenge in this case is that 1) the DockState enum is sequential (see comment above on terrible API design) and 2) there is no separate AutoHide property for DockContents.  So the only way to cleanly map between them was some sort of conditional construct.  This seemed like the cleanest method.

edit: Related, let me just say whoever came up with short-circuiting for logical and/or is a freaking genius.  Being able to encode a null check and property access in one operation is pretty much the best thing ever.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on October 18, 2015, 05:05:06 pm

Code: (csharp) [Select]

bool autoHide = Core.Settings.AutoHidePanes.Contains(name);
DockState state = plugin.DockHint == DockHint.Float ? DockState.Float
    : plugin.DockHint == DockHint.Left ? (autoHide ? DockState.DockLeftAutoHide : DockState.DockLeft)
    : plugin.DockHint == DockHint.Right ? (autoHide ? DockState.DockRightAutoHide : DockState.DockRight)
    : plugin.DockHint == DockHint.Top ? (autoHide ? DockState.DockTopAutoHide : DockState.DockTop)
    : plugin.DockHint == DockHint.Bottom ? (autoHide ? DockState.DockBottomAutoHide : DockState.DockBottom)
    : DockState.Float;  // stacked and nested ternary = awesome



Sometimes, integral enumerations are very convenient :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: N E O on October 19, 2015, 03:22:08 pm
Wait, why couldn't you use a switch block on that instead? You said the constants enumerate to ints, right?
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 19, 2015, 03:26:53 pm
The switch block would be more verbose.  This is nice and concise at 5 lines, a switch would be about double that.

By way of example, compare the above to:

Code: [Select]
switch(dockHint) {
case DockHint.Left:
if (autoHide) state = DockState.DockLeftAutoHide;
else state = DockState.DockLeft;
break;
// repeat for each case
}


I'm a firm believer in DRY. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Flying Jester on October 19, 2015, 05:40:44 pm
I think the real answer is clearly that autohide should not be a part of that enumeration at all.
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on October 19, 2015, 07:02:39 pm
I agree, but I didn't design the API.  Which is what makes that stacked ternary so impressive (to me, anyway)--it maps a terrible enumeration setup to a much more sane one.  I'm resourceful and good at working with what I'm given. :)
Title: Re: Radnen's Sphere Studio v1.1.7.0
Post by: Fat Cerberus on January 19, 2016, 05:20:22 pm
Sphere Studio somewhat runs under Wine now.  It shows the IDE and the initial configuration, but there's a pretty big showstopper: Attempting to do pretty much anything, creatinng a new project or even just opening the API reference, makes it lock up completely.  And Mono won't run it at all.  So... yeah, it seems it's still a long way off from getting this to run on Linux. :(
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Radnen on February 08, 2016, 02:21:02 am
Ok everybody, version 1.2.0 is out now.

It's been something Lord English and I had been working on for a while now, from draft to execution. Most of it was his ideas for propelling minisphere into the future, this included things like the debugger and project settings overhaul, among other things (such as the console output window). Go check it out!
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Fat Cerberus on February 08, 2016, 02:23:10 am
Nice, this was a lot of fun to make happen. ;D  By the way there's an Inno Setup script in the repo you can use to make an executable installer.

edit: I went ahead and attached the installer to the GitHub release:
https://github.com/Radnen/spherestudio/releases/tag/1.2.0
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: FBnil on February 12, 2016, 07:51:39 am
hey nice! downloading later (I am on my break, but supposed to be working)
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Fat Cerberus on February 12, 2016, 10:49:35 am
@FBnil: I re-uploaded the files for Radnen because I discovered that he mistakenly posted an outdated build, as a result the link in the OP is broken.  Here are working links:
https://github.com/Radnen/spherestudio/releases/download/1.2.0/SphereStudio-1.2.0.exe (installer)
https://github.com/Radnen/spherestudio/releases/download/1.2.0/SphereStudio-1.2.0.zip (zip)
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Radnen on February 13, 2016, 11:53:34 am
Oh,  I did. Sorry guys! I guess I chose the wrong folder, perhaps was building in Debug mode and forgot to make a Release build for the archive. :P
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Fat Cerberus on February 13, 2016, 11:58:21 am
@Radnen You should update the OP, the link is broken now and I can't edit your post (unlike the GitHub release post).
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Radnen on February 13, 2016, 08:45:16 pm

@Radnen You should update the OP, the link is broken now and I can't edit your post (unlike the GitHub release post).


Ok, I just pointed the link to the GitHub release tag, since it contains all the downloads.
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Defiant on February 18, 2016, 10:45:04 pm
So, I got a new (to me) laptop that has Windows 10 on it, and didn't have much choice to use this editor since the Vanilla one locks up when I try to edit an image.

Umm.... where do I edit resolution?

No hot keys for copy & paste in the script editor? That's a bit frustrating.

Sometimes when I load up the editor from turning on my computer, errors tend to fly...Not sure if it's something I'm missing or what..
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Fat Cerberus on February 18, 2016, 11:45:09 pm

So, I got a new (to me) laptop that has Windows 10 on it, and didn't have much choice to use this editor since the Vanilla one locks up when I try to edit an image.

Umm.... where do I edit resolution?

No hot keys for copy & paste in the script editor? That's a bit frustrating.

Sometimes when I load up the editor from turning on my computer, errors tend to fly...Not sure if it's something I'm missing or what..


Copy and paste, the normal Windows hotkeys for that should work (Ctrl+C, Ctrl+V), at least it does for me.  Believe me, I would be fixing that in a jiffy if it didn't!  The resolution should be editable in Project Properties, if not I'll check into it.

Don't know about the errors.  It's been working flawlessly for me for months on end.
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Fat Cerberus on February 23, 2016, 04:06:19 pm
Turns out I accidentally removed the resolution selector when I redid the dialog boxes.  Oops! :-[  Here's a fixed build:
https://drive.google.com/open?id=0BxPKLRqQOUSNdkRQZ2VvRlpfcHc
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Fat Cerberus on March 02, 2016, 11:46:58 pm
So I found out that ObjectListView is not compatible with Mono:
http://objectlistview.sourceforge.net/cs/faq.html#does-it-work-with-mono

I wonder if this is the reason Sphere Studio won't load under Mono...
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: DaVince on March 03, 2016, 12:59:56 am
It probably contributes, but I think there's probably more that causes issues.

Have you tried running the editor in a terminal? It always outputs a whole bunch of stuff that can probably be pretty indicative of what's missing/needed/where it crashes.
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Fat Cerberus on March 03, 2016, 01:10:30 am
When I tried it under Windows Mono, I got no output whatsoever, unless I used mono -v in which case it just logged the creation of the default Exception instances (OutOfMemoryException, NullReferenceException, etc.).  It took me a bit to realize that was just runtime logging and not related to Sphere Studio specifically.

I'll try installing Mono on my Ubuntu VM and see what happens there.  That might let me use gdb too.
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: Radnen on March 03, 2016, 01:51:47 am
ObjectListView is part of the task list plugin. If you don't load it, there shouldn't be a problem. Someday we can make a task plugin that is Mono compatible.
Title: Re: Radnen's Sphere Studio v1.2.0
Post by: DaVince on March 03, 2016, 02:51:22 pm

When I tried it under Windows Mono, I got no output whatsoever, unless I used mono -v in which case it just logged the creation of the default Exception instances (OutOfMemoryException, NullReferenceException, etc.).  It took me a bit to realize that was just runtime logging and not related to Sphere Studio specifically.

I'll try installing Mono on my Ubuntu VM and see what happens there.  That might let me use gdb too.

Well, I'm getting decent output in Mono under Ubuntu, so:

Code: [Select]
vincent@corine-Aspire-5538G ~/D/p/s/S/SphereStudio-1.2.1> mono Sphere\ Studio.exe
SendMessage (100663336, 0x101f, (nil), (nil))
SendMessage (100663336, 0x1003, 0x3, (nil))
SendMessage (100663336, 0x109b, (nil), 0x7fffd6c882b0)
SendMessage (100663336, 0x1036, 0x2000000, 0x2000002)
SendMessage (100663336, 0x1027, (nil), (nil))

Unhandled Exception:
System.EntryPointNotFoundException: GetScrollInfo
  at (wrapper managed-to-native) BrightIdeasSoftware.NativeMethods:GetScrollInfo (intptr,int,BrightIdeasSoftware.NativeMethods/SCROLLINFO)
  at BrightIdeasSoftware.NativeMethods.GetScrollPosition (System.Windows.Forms.ListView lv, Boolean horizontalBar) [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.get_LowLevelScrollPosition () [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.BuildList (Boolean shouldPreserveState) [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.BuildList () [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.DoUnfreeze () [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.Unfreeze () [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.set_Frozen (Boolean value) [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.System.ComponentModel.ISupportInitialize.EndInit () [0x00000] in <filename unknown>:0
  at SphereStudio.Plugins.TaskList.InitializeComponent () [0x00000] in <filename unknown>:0
  at SphereStudio.Plugins.TaskList..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) SphereStudio.Plugins.TaskList:.ctor ()
  at SphereStudio.Plugins.PluginMain.Initialize (ISettings conf) [0x00000] in <filename unknown>:0
  at SphereStudio.PluginShim.Activate () [0x00000] in <filename unknown>:0
  at SphereStudio.PluginShim.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0
  at SphereStudio.CoreSettings.Apply () [0x00000] in <filename unknown>:0
  at SphereStudio.Forms.IDEForm..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) SphereStudio.Forms.IDEForm:.ctor ()
  at SphereStudio.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: GetScrollInfo
  at (wrapper managed-to-native) BrightIdeasSoftware.NativeMethods:GetScrollInfo (intptr,int,BrightIdeasSoftware.NativeMethods/SCROLLINFO)
  at BrightIdeasSoftware.NativeMethods.GetScrollPosition (System.Windows.Forms.ListView lv, Boolean horizontalBar) [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.get_LowLevelScrollPosition () [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.BuildList (Boolean shouldPreserveState) [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.BuildList () [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.DoUnfreeze () [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.Unfreeze () [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.set_Frozen (Boolean value) [0x00000] in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.System.ComponentModel.ISupportInitialize.EndInit () [0x00000] in <filename unknown>:0
  at SphereStudio.Plugins.TaskList.InitializeComponent () [0x00000] in <filename unknown>:0
  at SphereStudio.Plugins.TaskList..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) SphereStudio.Plugins.TaskList:.ctor ()
  at SphereStudio.Plugins.PluginMain.Initialize (ISettings conf) [0x00000] in <filename unknown>:0
  at SphereStudio.PluginShim.Activate () [0x00000] in <filename unknown>:0
  at SphereStudio.PluginShim.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0
  at SphereStudio.CoreSettings.Apply () [0x00000] in <filename unknown>:0
  at SphereStudio.Forms.IDEForm..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) SphereStudio.Forms.IDEForm:.ctor ()
  at SphereStudio.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0


Dunno if I'm missing any crucial dependencies, but I notice this error is different than ones I have posted before.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 03, 2016, 03:00:36 pm
What happens if you delete TaskListPlugin.dll?
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: DaVince on March 03, 2016, 03:33:24 pm
Oh wow. Oh my god. It actually opens. A lot doesn't do anything/is bugged/makes it freeze, but I can actually change the settings, and even open a project and view its files. Didn't expect that whatsoever.

So far, what didn't work:
- The Open icon in the task bar just does nothing
- Using File > Open Project, I have to manually type game.sgm in a game folder in order to actually open the project.
- Double-clicking any file just makes the interface freeze until I close the program.

In any case, I didn't expect it to run natively at all, so this is quite nice!
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 03, 2016, 03:58:32 pm
Thats great, it'll give me a basis to start debugging from.  I wonder if the freezes/crashes are the same thing that happens under Wine... in any case this is good that it opens - I can probably use GDB to track down the rest of the bugs.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 04, 2016, 03:33:12 am
Regarding the manual open by typing game.sgm: That's actually not a bug, but by design in v1.2 - you're intended to upgrade SGM projects to .ssproj (there's a menu item for that) which allows using all the new project features, like building for minisphere with Cell, selecting different engines, etc.

I'm actually surprised it opened the project at all without an .ssproj file present! :o
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: DaVince on March 04, 2016, 06:42:28 pm
Oh, okay. From a usability standpoint, might it not be better to display the SGM files anyway and show a dialog to convert it to .ssproj right away when trying to open them, and then opening that? There's so many Sphere games out there with just an sgm, so... :)
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 04, 2016, 09:11:23 pm
That's probably a good idea, I'll see about fixing that.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 19, 2016, 01:19:44 am
@Radnen: I'm currently looking into upgrading the script plugin to use the latest Scintilla from NuGet, which would allow the Scintilla DLLs to be removed from the repo.  It's not going to be easy though: You thought the Scintilla API was bad before?  They somehow managed to make it even worse! :o  They completely reorganized and refactored all the methods and properties and somehow it's NOT an improvement at all.  I was about to give up to be honest, but I figure this will probably be needed now in order to support syntax highlighting for TypeScript and CoffeeScript code (especially the latter--TS can probably get by for now with standard JS highlighting).

By the way, what is the license for Sphere Studio?  The main LICENSE file says GPL3, but I also remember finding an MIT license in there somewhere.  So I'm not sure.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 19, 2016, 01:27:33 am

@Radnen: I'm currently looking into upgrading the script plugin to use the latest Scintilla from NuGet, which would allow the Scintilla DLLs to be removed from the repo.  It's not going to be easy though: You thought the Scintilla API was bad before?  They somehow managed to make it even worse! :o  They completely reorganized and refactored all the methods and properties and somehow it's NOT an improvement at all.  I was about to give up to be honest, but I figure this will probably be needed now in order to support syntax highlighting for TypeScript and CoffeeScript code (especially the latter--TS can probably get by for now with standard JS highlighting).


Yeah, I saw that too. Then I realized how much of a pain the new API became. I just didn't have the time to learn it all. I mean, I felt good after cracking the old API. Now... eh, no thanks. Did you notice any feature improvements? Or is the API too convoluted to not notice XD. One thing I want to see someday is a style editor. Because I've been preferring darker text editors than white/light editors. It's easier on the eyes.


By the way, what is the license for Sphere Studio?  The main LICENSE file says GPL3, but I also remember finding an MIT license in there somewhere.  So I'm not sure.


I'm not sure about the license either! I wanted GPL3 because I could bundle it with Sphere. But then I thought MIT was very attractive and wanted to use it too.

Ugh... I'd go with MIT License since I don't care anymore about bundling this with Legacy Sphere.

edit: I hope you... agree? I'll need your consent in writing I think. I'm changing it now to MIT. BTW, I think we need to start copy-pasta the MIT all over the codebase. Ugh... I hate doing that. <cringes>
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 19, 2016, 03:59:34 am
Oh right, I contributed a bunch of code. :P. I don't mind at all, I'll gladly relicense my contributions under MIT.  I prefer that over GPL anyway.

As for Scintilla, the new version does seem to have much better syntax highlighting features at least, I was experimenting with it before.  We'll be able to have it highlight Sphere API function names and stuff like that in a different color, which was previously impossible.  It also seems to have basic Intellisense too, but I haven't figured out how to use it properly.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 19, 2016, 01:20:11 pm
Here's a screenshot of my progress on the Scintilla conversion so far.  A few things are broken right now: Stupid things like Ctrl+F doesn't open the Find dialog, etc. that I will have to figure out.  But the syntax highlighting in this version is much, much better!
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 19, 2016, 07:25:45 pm
Awesome! Is there an xml that can be configured. Because one of these days adding a style editor would be fantastic.

Also, I wonder how much trouble it is to use a parser like ANTLR to do code formatting and intellisense?
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 19, 2016, 07:49:03 pm
The keyword list for Sphere API functions is stored as a separate text file (Dictionary/SphereAPI.txt), my next step was to put the default coloring and font parameters into its own XML file too, but I didn't do that yet because I'm still experimenting and figuring out which colors work best for which keywords.  My current scheme:

* Blue - JS keywords (like MSVC)
* Purple - "pseudo-keywords" which have special meaning but might be redefined, e.g. eval, global, undefined (!)
* Cyan - Sphere API (current to minisphere 3.0rc6)
* Dark red - strings and number literals
* Green - comments
* Pale yellow - Current Line highlight
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 20, 2016, 02:56:14 am
This is going to be a bigger undertaking than I thought: it seems the new control was recoded from the ground up and lost a lot of functionality it had previously.  For instance Find/Replace is no longer built-in so I'd have to implement that myself.  Since I don't feel like going down that road right now I moved the changes thus far onto a separate branch to avoid loss of functionality in the master builds.

I agree about the style editor.  I've dabbled with dark themes myself, and if the syntax highlighting colors are well chosen, it's really a lot easier on the eyes than the typical white-on-black.  A lot of that I think is that, with a dark theme, you don't need to have a lot of contrast to be usable: You can have silver text on a gray background and it's fine, whereas with a white background you need black or very dark colors in order for everything to remain readable.

But yeah, I'm not really up to coding in the missing features right now, so we can maybe revisit this some other time.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 21, 2016, 01:47:45 am
Just to clarify, I still want to go through with the change, but noting that it requires extra effort to be made and so will likely take a while longer.  That said, having Sphere API calls highlighted in the source is really nice, as you can see in the screenshot below.  If you make a typo, you'll know because the function won't turn purple.

Anyway, being forced to rewrite the Find/Replace dialog might not be such a bad thing, though.  The huge Find dialog is kind of an anachronism at this point.  It would be nice to take a leaf from MSVC and modern browsers and implement a mini search bar that pops up at the top of the script view when you press Ctrl+F and highlights text as you type.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 21, 2016, 02:03:14 am

It would be nice to take a leaf from MSVC and modern browsers and implement a mini search bar that pops up at the top of the script view when you press Ctrl+F and highlights text as you type.


Yes, I was wanting to do this for some time. If this is the time to do it, the please be my guest. :)

Oh, BTW I'm adding a new feature, the master palette. It's attached to the ImageEditControl, what it does is shows you the palette used by the whole image. If you change a color there, it changes every pixel automatically. It's useful for map editing when you want to edit multiple tiles pixel colors all at once than painstakingly selecting them one at a time.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 21, 2016, 02:18:00 am
That's a neat idea.  That was one great convenience we lost in the transition from 256-color to truecolor displays: The ability to change colors quickly at a high-level using palette manipulation.  I remember that fondly from my QB 4.5/mode 13 days. :)  Nowadays if you want to do something similar to that in realtime you can get the effect using shaders, but for a long time it just wasn't possible.

Since Sphere tiles and sprites are actually truecolor I assume it'll be implemented via search-and-replace on the pixels themselves?
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 21, 2016, 02:27:27 am

I assume it'll be implemented via search-and-replace on the pixels themselves?


Yep. I'm leveraging the ReplaceColor feature I already have in the image edit control. Since it affects the image edit control, for maps you must select all of the tiles before you can use the new feature. I didn't feel like creating a special version for sprites, tiles and images, so I just created the one for the image editor. It's still very easy to use and is enabled everywhere the image editor is.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: N E O on March 21, 2016, 04:26:35 pm

Oh, BTW I'm adding a new feature, the master palette. It's attached to the ImageEditControl, what it does is shows you the palette used by the whole image. If you change a color there, it changes every pixel automatically. It's useful for map editing when you want to edit multiple tiles pixel colors all at once than painstakingly selecting them one at a time.


OMG I've wanted this in the editor for over a decade and hated having to select multiple tiles to edit many at once to do the color replacement. I was too lazy to figure out the map editor myself to add it, so good stuff dude!
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 22, 2016, 01:53:00 am
The new search bar is coming along nicely.  Still has a couple bugs in it, but it mostly works as designed.  See screenshot attached.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 22, 2016, 11:35:58 am
Nice job!

I haven't tried it out, so this is just a list to make sure the UX is decent:

1. Make it so that when you select a word and hit Ctrl+F, it pre-populates the dialog like in Visual Studio.
2. And make it so that when you do that with Ctrl+F, hitting Ctrl+H turns it into the Search & Replace without losing the settings.
3. Then if the dialog is popped up and you hit enter, either search or search & replace the text in the text boxes. This is about focus, we shouldn't have to click on the box when we hit Ctrl +F to search and replace your brain is in "search and replace mode".

With those 3 things working, the search and replace will feel like it's not there. ;)

As for the palette selector, I have finished it. The hardest part is ordering the colors correctly. Right now I'm just ordering by Hue. But there always seem to be outliers in the sort. That's because 3 components make up a color: HSL or RGB. But by ordering by lightness curves, etc. it is still not perfect. In fact I have found no good algorithm for this. A very few solutions online are quite accurate, but still they only get it right about 90% of the time. But for our human eye, we know how to sort colors, a problem devilishly complex for a computer to solve.

Do you guys care about perfectly sorted colors?

Anyways, that said, following the MVC approach on the component (separation of concerns and what-not) meant that the colors update automatically, you get undo/redo, and no extra code was needed to bridge the gap between the component and the replace color functionality of the editing control. All in all, it was a very easy and sweet integration and I'm sure the artists of this community will absolutely love it. I'll have it ready much later today when I return home from work.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: HopeMetal on March 22, 2016, 11:47:15 am

As for the palette selector, I have finished it. The hardest part is ordering the colors correctly. Right now I'm just ordering by Hue. But there always seem to be outliers in the sort. That's because 3 components make up a color: HSL or RGB. But by ordering by lightness curves, etc. it is still not perfect. In fact I have found no good algorithm for this. A very few solutions online are quite accurate, but still they only get it right about 90% of the time. But for our human eye, we know how to sort colors, a problem devilishly complex for a computer to solve.

Do you guys care about perfectly sorted colors?

Maybe make it possible to rearrange the colors after they've been roughly sorted?
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 22, 2016, 01:10:44 pm

Nice job!

I haven't tried it out, so this is just a list to make sure the UX is decent:

1. Make it so that when you select a word and hit Ctrl+F, it pre-populates the dialog like in Visual Studio.
2. And make it so that when you do that with Ctrl+F, hitting Ctrl+H turns it into the Search & Replace without losing the settings.
3. Then if the dialog is popped up and you hit enter, either search or search & replace the text in the text boxes. This is about focus, we shouldn't have to click on the box when we hit Ctrl +F to search and replace your brain is in "search and replace mode".

With those 3 things working, the search and replace will feel like it's not there. ;)


I merged my changes into master.  Since your change is to an unrelated component (image editor), there shouldn't be any conflicts.

All your points above should be covered.  I went to great pains to make it behave exactly like MSVC's search box, which involved a lot of screwing around and trying different things (basically the same method I used to make minisphere compatible with Sphere 1.x -- brute-force reverse engineering :P)

WinForm's handling of focus doesn't exactly align with the UI goals of this type of component, so parts of the code may be hard to follow.  So I added a paragraph to the top of the search box code explaining the intended behavior:
https://github.com/Radnen/spherestudio/blob/master/ScriptEditPlugin/Components/SearchBox.cs#L21-L37
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 22, 2016, 01:44:33 pm
One thing I'd like to see in the future is file system monitoring in the script plugin so that, if a script file changes outside the IDE, it's automatically reloaded, or prompts to do so if there are unsaved changes.  This is one thing that comes in handy in MSVC when working with version control.  I often find myself reverting changes through the GitHub client after I screw something up, and it's annoying to have to close the file and reopen it.  And then if you forget to do that, you end up un-reverting the reverted changes. :P
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 22, 2016, 04:10:18 pm

All your points above should be covered.  I went to great pains to make it behave exactly like MSVC's search box, which involved a lot of screwing around and trying different things (basically the same method I used to make minisphere compatible with Sphere 1.x -- brute-force reverse engineering :P)


Sweet, that's exactly it. :)

@HopeMetal: That's nice if we get to save the colors boxes and keep them consistent. Unfortunately, for now it's auto-generated each time colors are changed on the source image. I think I'll just keep them sorted by Hue for now and iterate on this concept once I've released it.

I realized just now, I'm not handling alpha values at all. I had plans and some older code outlining a custom color selector. I might just have to go and complete it and add that in.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 22, 2016, 10:39:23 pm
Ok, I'm delaying the release of the master color palette editor. I'm going to add some useful features to it, like copy swaths of colors, and an eyedropper to find specific colors from the target image. These two will make it far, far more usable than it is now.

For example, if you select 4 colors of a bush and change them, then you've only changed it for that bush. If there is another bush and you want to copy the palette over to that one, you can't. So I'm going to add the ability to copy ranges of colors. The eyedropper is useful for discerning between two colors that look similar, but are different (if you know where to look on the source image, use the eyedropper, and then continue on like normal).

BTW, I separated the colors channels into distinct red, green, blue, and greyscale groups, sorted them, and then stitched it back together. I got a much cleaner looking result.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 22, 2016, 10:58:55 pm
Have you tried the new search bar?  I think I finally got all the bugs out of it. :)
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 23, 2016, 01:08:44 am
On a sidenote, recent MSVC versions must have some kind of crazy awesome parser... you can put the cursor on a variable or function name, and not only will it highlight all occurrences of it, but it shows ONLY real matches, i.e. it respects scope, whether it's a variable or function, etc.  It's incredibly useful, and just another thing that makes MSVC one of the best IDEs ever made, despite its bloatedness.  If only the same could be said for its C++ compiler...

That highlighting feature is something I would love to see in Sphere Studio someday, but alas, Scintilla isn't quite that powerful.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 23, 2016, 01:22:57 am

That highlighting feature is something I would love to see in Sphere Studio someday, but alas, Scintilla isn't quite that powerful.


Hmm, I figured the syntax highlighting would be tied directly to the language parser. We'd have to use ANTLR or some library like it to create our own parser, and then highlight pieces of an AST on demand. It's doable, but not easy nor quick to achieve.

I pulled the code and tried it out. It works very well! :) But I still got it to a state where hitting ESC didn't close it. And then I assume the style will come later, because right now it looks a bit bland. Also integration with the currently selected theme would be nice to have as well. But all in all, it serves it's basic use and the regex search is just as good as any so I'm happy.

Then a future bonus would be to search current file, opened files, and all files. But that may need more of a backend change, perhaps when we add the feature to detect changes from the filesystem. That said, the project list knows, I think what we need is a dedicated link between an item on the project list and the opened document. My first version of this editor had that, I was able to (as a demonstration) highlight the file that was opened as well as handle file renaming. I'm pretty sure once we do that, the rest ought to be easier to manage.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 23, 2016, 01:36:16 am
The thing is that Scintilla uses a generic "C++" parser to handle all languages with a C-like grammar, including JavaScript.  Semantics and scope handling vary between languages so I guess it's not possible with the stock functionality.  Oh well, something to add to the wishlist.

The ESC bug was actually fixed in my working copy, but I never made a commit for it.  It's fixed in master now.  Let me just say that WinForms keyboard handling is not one of its strong suits, it took me a while to figure out the right way to handle hotkeys and such!  But I agree that it's bland-looking.  I'll work on sprucing it up a bit in my spare time, I just wanted to get it functional since not having a search feature was a major blocker for the Scintilla upgrade, and it served as a perfect excuse to implement QuickFind. :D

As for Find in Files, yes, that was the next thing I wanted to tackle, but it's a tricky thing--you only want to look at code files, and with the plugin system abstracting all the file types and such away, it's a bit more difficult than when the editor was completely monolithic.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 23, 2016, 03:54:55 pm
Okay, I made the Quick Find control style-aware.  It's still a bit plain, but now it matches the current style at least, so it doesn't stick out like a sore thumb.

It seems there's only so much you can really do with WinForms.  As much as I hate the complexity of WPF and similar frameworks, I can understand the appeal.  You can make very rich interfaces with it (see: MSVC 2010 and later) whereas WinForms is quite utilitarian and rooted in rectangular controls.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 23, 2016, 11:50:43 pm
I forgot to post a screenshot before.  Here's what the Quick Find box looks like now.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 23, 2016, 11:58:14 pm

It seems there's only so much you can really do with WinForms.  As much as I hate the complexity of WPF and similar frameworks, I can understand the appeal.  You can make very rich interfaces with it (see: MSVC 2010 and later) whereas WinForms is quite utilitarian and rooted in rectangular controls.


Yeah, I agree here, but it's still very simple to just build the code out and "get it done". I've always found WPF a hassle to deal with, I mean html and css is easier than that. XAML? I mean come on!

Nice screenshot, BTW. I've been very busy and so I have not had the time to do anything lately. So, here's a screenshot of what I'm doing at the very least.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 24, 2016, 01:31:41 am
That palette feature does look really useful.  Especially for pixel art with a limited number of unique colors, I imagine it would be invaluable.  Oh, I don't know if you noticed in my screenshot, I finally found the Goldilocks point for the code font size.  I found the 10 point to be too small and the lines too close together, but 11-point was too large, especially on lower-resolution displays.  The solution: It turns out you can specify fractional point sizes.  What you see in that screenshot is 10.25-point Consolas.

Anyway, I need to stop screwing around with Sphere Studio so I can finish polishing off minisphere for the 3.0 release. ;)
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: DaVince on March 24, 2016, 04:41:53 pm
Sphere-related tools getting improved is never "screwing around", if you ask me. Good work on this. :)
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 25, 2016, 07:19:40 pm
@Radnen: I wrote a proper introduction in the README file:
https://github.com/Radnen/spherestudio
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 26, 2016, 01:10:51 am

@Radnen: I wrote a proper introduction in the README file:
https://github.com/Radnen/spherestudio


Thanks, it needed a good update. :)
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 28, 2016, 02:16:24 am
By the by, I ended up releasing minisphere 3.0 with a bundled copy of Sphere Studio after all.  I figured why not, the vanilla engine included an editor, so minisphere should include a modern one.  The bundled version incorporates my latest changes and UX improvements as 1.2.2, so if you want to do a minor maintenance release with that version number, that would probably be good to avoid confusion.  Just if you do, make sure to do a full clean and rebuild this time. :P  I've gotten into the habit of doing that for all my releases, so I know that everything's up to date before packaging.  Sometimes I'll even go as far as deleting the build directory completely to make sure all the stale files get nuked.

At one point I was considering forking the editor and bundling it as "minisphere Studio" (versioned in sync with the engine and toolchain, with all changes contributed back to the main repo of course), which the MIT license would allow, but I decided that probably wasn't a good idea.  Fragmentation is bad. ;)
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 28, 2016, 05:01:21 pm
Oh. I would have liked to add that dynamic palette I was working on, but lately I've just been so darn busy. Tonight I may work some more on it, and perhaps add it to the codebase. It's fully working but a bit difficult to use. I wanted to add an eye dropper and copy-paste/merge ability to the palette.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 28, 2016, 07:16:28 pm
One thing that's a pain now that Sphere Studio uses semantic versioning is that I have to be very careful when making changes not to break the plugin API.  Being a huge perfectionist, I'm often tempted to do mini-refactorings on the plugin system but have to stop myself because it would break plugins.  For bundled plugins this isn't a problem (they can just be recompiled along with the editor), but it is for third-party ones like the minisphere debugger because it would break both backward AND forwards compatibility.

To clarify a bit, in .NET it's safe to add new methods and classes without breaking anything, but changing method signatures (= return type, adding/removing/reordering parameters) or names will break plugins.  This is the main thing holding me back from redoing the styling API (it badly needs an update), because I haven't yet figured out how to do it and still keep plugin compatibility.

Incidentally this is one thing I don't like about the way async/await is set up: you can't change a method between async and sync without it being a breaking change.  I understand why that's the case for technical reasons, but that doesn't make it any less frustrating. :P
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 28, 2016, 10:04:36 pm

One thing that's a pain now that Sphere Studio uses semantic versioning is that I have to be very careful when making changes not to break the plugin API.  Being a huge perfectionist, I'm often tempted to do mini-refactorings on the plugin system but have to stop myself because it would break plugins.  For bundled plugins this isn't a problem (they can just be recompiled along with the editor), but it is for third-party ones like the minisphere debugger because it would break both backward AND forwards compatibility.

To clarify a bit, in .NET it's safe to add new methods and classes without breaking anything, but changing method signatures (= return type, adding/removing/reordering parameters) or names will break plugins.  This is the main thing holding me back from redoing the styling API (it badly needs an update), because I haven't yet figured out how to do it and still keep plugin compatibility.

Incidentally this is one thing I don't like about the way async/await is set up: you can't change a method between async and sync without it being a breaking change.  I understand why that's the case for technical reasons, but that doesn't make it any less frustrating. :P


I understand the pain of the async/sync even at where I work. I guess if it's got to be done I can't see why not bumping up the version numbers considerably. v1.2.214 anybody? Anyways we don't have to release with each minor bug fix, so it's okay to go several releases and then release when we reach the middle or end of each month.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 28, 2016, 10:16:07 pm
Strictly speaking, by semantic versioning rules, if you break any APIs at all, you're supposed to bump the major version (1.x -> 2.x -> 3.x, etc.)  I tend to ignore that rule though because I don't want to end up releasing a hundred major versions in a year (minisphere would be up to v812.0 by now). :P  Usually if it's only a small change I'll "cheat" and just update the minor version (1.2 -> 1.3, for instance), or if I think the change won't affect anyone I've even been known to introduce breaking changes in a bugfix release.

I'm actually not sure how binary compatibility works in C#.  For example, can you change a method's parameters and only have it affect plugins that call that method, or will any breaking change prevent the assembly from being used entirely?  I feel like it's the former (which would make the most sense), but with .NET having strong naming and other such systems, it's not totally clear.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on March 28, 2016, 10:55:06 pm
AFAIK, if you use optional parameters, you're fine: http://stackoverflow.com/questions/12670735/is-replacing-an-optional-parameter-with-overloads-a-breaking-change

But I'm pretty sure a breaking change is a breaking change.


Strictly speaking, by semantic versioning rules, if you break any APIs at all, you're supposed to bump the major version (1.x -> 2.x -> 3.x, etc.)


Hmm, I don't do that. If I break an API I bump the middle number. :P I bump the first number if it's been structurally overhauled in a major way. Otherwise small bug fixes ought to not be a problem.

BTW for Async/Sync issue, what we do at work and what is standard for .NET is to end the method call with 'Async' like "GetTransactionAsync()" and keep the older synchronous method call in place. Now, for a plugin system, I'm not sure what happens when you run two different versions of a DLL, in which the second DLL has only new stuff added to it. I think it will still work.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 28, 2016, 11:18:42 pm
Yeah, I'm the same way.  The official definition of semantic versioning is supposed to be, given X.Y.Z:



But that's ridiculous because it makes refactoring anything very difficult.  A major version bump carries a lot of emotional weight not only for the developer but end-users as well, so you want to avoid doing it unnecessarily.  This makes it hard to make necessary changes.  So my take on versioning instead leans more towards:



It also allows for faster development when you're free to introduce features in a tertiary release. :)

Note that I said "ABI" instead of "API" above.  To me at least, source-level compatibility really doesn't matter since if you already have the ability to build from source, you can also make the necessary edits.  What matters here is binary compatibility: Can I swap out the underlying platform for a new version and still have everything work?  If so, it's non-breaking, even if source-level compatibility has been broken. (the term "binary" is a bit loose here of course--with some platforms like Sphere or Node.js, the API and ABI are one and the same).

So yeah, that's my two cents. :P
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on March 29, 2016, 02:24:14 pm
@Radnen: Alright, here's what I decided to do to avoid needing premature releases: For bundled copies of Sphere Studio, I'll use the version number of the most recent official Sphere Studio release and just add any fixes I need to make on top of that.  Only when you make an official release will I bump the version.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on April 16, 2016, 03:01:02 am
I just added a Sphere 1.x compatibility mode to Sphere Studio:
https://github.com/Radnen/spherestudio/commit/bd9696832e952b43704dae9af95f9c38b829fb94

Now when you open an SGM file, instead of forcibly replacing it with an .ssproj file and making the project incompatible with the classic editor, it still creates the .ssproj but also keeps the game.sgm up to date when saving the project.  Unless you explicitly tell the editor to upgrade the project (needed in order to take advantage of advanced stuff like Cell integration), it will remain in compatibility mode so you can use either editor.

Oh, and also, legacy projects are listed on the Start Page again.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: mezzoEmrys on July 02, 2016, 06:13:42 pm
I don't know if this is a known bug, but I had accidentally typed two parenthesis at the start of a function as
Code: [Select]
CreateColor((255, 255, 255);

And after starting up minisphere and informing me of a parse error, Sphere Studio crashed.

Code: [Select]
Problem Event Name:	CLR20r3
  Problem Signature 01: Sphere Studio.exe
  Problem Signature 02: 1.2.1.0
  Problem Signature 03: 574db54c
  Problem Signature 04: Anonymously Hosted DynamicMethods Assembly
  Problem Signature 05: 0.0.0.0
  Problem Signature 06: 0
  Problem Signature 07: 0
  Problem Signature 08: ffffffff
  Problem Signature 09: QCQUMZNLVZFTVMBQQ2DV1TYSC5H01EH3
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1033
  Additional Information 1: 6198
  Additional Information 2: 6198e9636daaf1a3eec7a0f2bce0d363
  Additional Information 3: c60f
  Additional Information 4: c60f3d47aa79c2d74c76cad6601c23cf

Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on July 02, 2016, 08:08:30 pm
Windows 6.1.7601, what is that, Vista?

I'll look into it tonight.  There are some known (to me) glitches related to the debugger that can cause the entire editor to crash, so this might be related.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: mezzoEmrys on July 02, 2016, 10:09:03 pm

Windows 6.1.7601, what is that, Vista?


Nope, just bog standard Windows 7 Professional Service Pack 1 (http://www.jrsoftware.org/ishelp/index.php?topic=winvernotes). In fact, even windows 8 is only 6.2, and 8.1 is 6.3.

Found a slightly different bug, sometimes on encountering an error which points to a line number, it seems like SSJ doesn't inform the editor to stop highlighting the line in red, so after a while of writing and debugging, I have to reload the file to get rid of the 4 red lines I can't manually remove.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on July 03, 2016, 02:40:05 am
Okay so the crash on syntax error is a bug in the SSJ plugin, not Sphere Studio itself.  Basically because it's a parse error, there is no callstack, so the debugger gets confused when it goes to highlight the offending line.  Should be pretty easy to fix, maybe I'll do a 3.3.1 release since minisphere 4.0 isn't quite there yet (unless I release it without the new map engine).

Haven't tracked down the cause of the sticky error highlight yet, but I've noticed it a few times myself.  I'll keep testing, I guess an event isn't being fired or something.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on July 03, 2016, 03:34:24 am
On a side note, good to hear someone is getting some mileage out of the Sphere debugger. ;D
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Eggbertx on September 21, 2016, 02:46:37 pm
Now that .NET Core has been ported to Linux (I'm pretty sure at least), how difficult would it be to port this to Linux?
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: N E O on September 24, 2016, 12:10:59 am
I'm now interested in seeing this on BSD as well! There seem to be mono and gtk-sharp ports available, so feasibility++ ?
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on September 24, 2016, 12:50:39 am
Sphere Studio and Mono don't get along, even on Windows, mostly because of ObjectListView and Scintilla.NET.  As for .NET Core, I don't know enough about it to say one way or the other.

Sphere Studio does run under Wine, but not without a lot of glitches and general brokenness.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on October 20, 2016, 11:34:48 am
So I'm finally satisfied with the color scheme in the code editor.  I wanted to set off different types of tokens so they can be easily distinguished from one another but still prevent elements like braces and operators from fading too much into the background.  By coloring it this way it's easy to skim through code to figure out what it's doing without giving the impression that the syntax is different than it really is (that is, even at a quick glance it's still obviously JS code you're looking at).

Screenshot attached.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Radnen on October 20, 2016, 10:25:29 pm
I like it. It's nice and subtle. But these days I have been using dark themes, and so I was wondering if we should add a theme selector to it. For the longest time I've wanted to make a style editor, but have so far been too busy/lazy to work on that.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on October 29, 2016, 01:17:11 pm
I would like to implement a dark mode, but when I tried it a while back Scintilla didn't cooperate.  The background color was dark but the text itself got rendered with a white background, which was beyond ugly.  I never did figure out how to fix it.

Maybe it would work better now that we're using an up-to-date Scintilla.NET control, I'll do some experimenting later.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: DaVince on November 04, 2016, 07:18:09 am
I happen to be on Windows right now and wanted to give Sphere Studio a shot, but the last release on Github seems to be from March. Is this right at all? I was so sure the latest release was newer than that...
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on November 04, 2016, 08:54:15 am
Yeah, Radnen hasn't made any new releases.  minisphere always bundles the latest build though.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: DaVince on November 05, 2016, 01:34:54 pm
I don't know if this was fixed in the meantime, but Sphere Studio crashes if I open it by opening an ssproj file. It doesn't crash immediately, though - it seems to open fine at first, but then crashes if I either try to open a different project on the Start Page or try to test the game I just opened.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on November 05, 2016, 01:53:23 pm

I don't know if this was fixed in the meantime, but Sphere Studio crashes if I open it by opening an ssproj file. It doesn't crash immediately, though - it seems to open fine at first, but then crashes if I either try to open a different project on the Start Page or try to test the game I just opened.


I noticed that bug about a year ago, I thought I fixed it but I guess not.  It seems to be some sort of race condition, I'll have to look into it again.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: DaVince on November 05, 2016, 01:56:00 pm
All right. :)

I also have a feature request! Build > Package game lets you package the game as an SPK. But could we also have a Build option where it includes minisphere with it, so that there's an easily distributable package even for people who don't have minisphere?

Actually, "package game" could be a dialog box, now that I think about it. It could contain options for how you want to build the game:
- Include minisphere (or old Sphere); this will package anything into a folder when selected.
- Package game files into a single file; this will make it package the files into an SPK instead of just including the game folder.
Title: Re: Radnen's Sphere Studio v1.2.1
Post by: Fat Cerberus on November 05, 2016, 02:02:13 pm
That's a good idea, I'll look into implementing that when I'm not preoccupied with adding features to minisphere ;)
Title: Re: The Sphere Studio v1.2.1
Post by: Radnen on November 14, 2016, 02:43:05 am
Uh, quick update, I renamed the topic to The Sphere Studio, because it has been sort of a community project for some time now, with Lord English/Fat Cerberus's help and all.

Come to think of it, I still haven't checked in that code for the master palette yet...
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on December 04, 2016, 04:12:16 pm
@DaVince: I'm gearing up to start working on minisphere 5.0, so I'll look into that game packaging idea.  One thing I think would be really nice is if the default JS modules, etc. could be packaged into the SPK too so then you only need to distribute minisphere.exe, without the system folder.  SphereFS would make that really easy to handle in the engine since filename canonization is built into the mechanism (i.e. the relative SphereFS path is canonical).
Title: Re: The Sphere Studio v1.2.1
Post by: DaVince on December 05, 2016, 05:06:21 am
Neat!

Edit: I posted something long here that I have moved into the minisphere thread now.
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on March 23, 2017, 01:23:57 am
I just added a SourceMapper class to Sphere.Core to allow debugger plugins to easily remap line numbers for transpiled code.  I needed source map support to be able to switch to TypeScript in miniSphere (since it doesn't have an option to preserve line numbers), and I figured it was better to make it a generic function in the editor rather than hardcoding it into the miniSphere plugin.
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on June 13, 2017, 10:40:30 pm
I'm planning on redesigning the Start page at some point in the near future.  It's starting to look pretty antiquated these days and it doesn't scale well at all to large numbers of games, even in Details view.  I'm thinking of making it like the Visual Studio Start page, where it only shows the 5 most recent projects worked on, with some sort of feed with links to Sphere documentation, resources, and news.  (hosting can be worked out later).

Maybe someone has suggestions for this to make it even better? ;)
Title: Re: The Sphere Studio v1.2.1
Post by: Eggbertx on June 13, 2017, 11:25:26 pm
That sounds like a pretty cool idea (which I'm totally gonna steal for QtSphere IDE :P)
Here is Qt Designer's home screen, if it gives you any inspiration.
Title: Re: The Sphere Studio v1.2.1
Post by: DaVince on June 14, 2017, 03:32:50 am
I agree, this sounds like a good idea. A feature I tended to use a lot in the old editor was "Open Last Project", after all. :D

Quote
with some sort of feed with links to Sphere documentation, resources, and news.  (hosting can be worked out later).

Sounds good to me. If we're going to have a news feed, it could be used on the website too. As for resources, wiki links would be good but it requires some serious update to the wiki itself.

Just keeping it simple and clear like Qt Designer's would be a good idea, I think.
Title: Re: The Sphere Studio v1.2.1
Post by: Radnen on June 14, 2017, 10:01:33 pm
Yeah, I agree. Imitating the VS start page would be great to have. +1
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on July 26, 2017, 11:19:42 am
Not much to report yet in terms of implemented features, but I did some minor refactoring and moved all the information strings into Sphere.Core so that they're easier to access in code (reading from AssemblyInfo.cs is very clunky) and make them easier to edit.

https://github.com/Radnen/spherestudio/blob/master/Sphere.Core/Versioning.cs

I might move the version number into Sphere.Core though, so bundled plugins can take their version numbers from there.  Then making a new version is just a matter of editing the version number in one place. :)  (edit: I made that change)

Tip: The latest bleeding-edge build of Sphere Studio is always included when a new miniSphere version is released. :D
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on July 28, 2017, 11:33:05 am
Here's a sneak peak at the dark theme I'm working on. ;D
Title: Re: The Sphere Studio v1.2.1
Post by: DaVince on July 28, 2017, 03:10:36 pm
Looks pretty... sublime! :P
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on July 29, 2017, 11:19:58 pm
It's coming along nicely.  The 3D edge effects applied by Windows are very distracting with a dark theme, I'll have to see if I can disable them.
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on August 01, 2017, 01:42:21 am
Almost there, just have to work some of the bugs out (switching projects usually crashes the IDE, and I don't know why yet)  I ended up embarking on a massive refactoring project in the process of implementing this.  The Sphere Studio codebase is much better organized now.

Anyway, here's a screenshot showing off lots of stuff. :)
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on August 01, 2017, 12:05:12 pm
Thanks to @Miscreant for tipping me off, I'm in the process of hunting down bugs in the spriteset and map editors that can cause the IDE to crash.  A lot of the default plugins are glitchy; it's fairly old code and suffering pretty badly from bit rot, especially with the all the refactoring going on around them lately.  This is largely my fault: I do all this refactoring to the core, but never touch the editor plugins.

C# is a joy to code in though, so I don't mind fixing stuff. :)
Title: Re: The Sphere Studio v1.2.1
Post by: Radnen on August 01, 2017, 09:11:25 pm
I'll admit the plugins were glitchy because at the time it was such a huge undertaking to recreate the massive amount of editors for sphere 1.x development. They never got the polish they deserve. The map editor in particular was recoded 3 times and while I'm happy with the current version for 1.x maps, there's still some stuff I'd love to have cleaned up.
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on August 01, 2017, 09:22:35 pm
By the way @Radnen, how do you like the new dark theme (based on the screenshots)?  It was tricky to get all the colors to work well together, but I really like the way it turned out.  I find it a lot easier to differentiate different parts of a statement compared to the classic colors.  For example there was one file I saw that had half of the code commented out but I didn't realize it until I switched to the Dark theme. :P
Title: Re: The Sphere Studio v1.2.1
Post by: Radnen on August 02, 2017, 12:18:06 am
I love the look. It's dark theme but not hard on the eyes. There's a softness to it I like. +1
Title: Re: The Sphere Studio v1.2.1
Post by: Rhuan on August 26, 2017, 06:31:47 am
Could someone refresh my memory as to why the Sphere Studio couldn't be made cross platform? What was the key windows on dependency? Could this be replaced?
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on August 26, 2017, 09:46:37 am
ObjectListView causes issues, I know that.  DockPanelSuite is supposed to work under Mono/Wine, but it's flaky.  But mostly it's OLV that breaks everything, I'm pretty sure.
Title: Re: The Sphere Studio v1.2.1
Post by: Chad Zechs on September 09, 2017, 05:02:17 pm
Not sure if this is one of the noted issues, but with the Sprite Editor, when I try to set delay, I get this:

Code: [Select]
See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
   at SphereStudio.Plugins.Components.DirectionLayout.SetDelayItem_Click(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.2102.0 built by: NET47REL1LAST
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
Sphere Studio
    Assembly Version: 0.0.0.0
    Win32 Version: 0.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Sphere%20Studio.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.2104.0 built by: NET47REL1LAST
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.2103.2 built by: NET47REL1LAST
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.2046.0 built by: NET47REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
SphereStudio.Base
    Assembly Version: 0.0.0.0
    Win32 Version: 0.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/SphereStudio.Base.DLL
----------------------------------------
System.Core
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.2102.0 built by: NET47REL1LAST
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Configuration
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.2046.0 built by: NET47REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.2102.0 built by: NET47REL1LAST
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
WeifenLuo.WinFormsUI.Docking
    Assembly Version: 2.16.0.0
    Win32 Version: 2.16.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
AudioPlayerPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/AudioPlayerPlugin.dll
----------------------------------------
FontEditPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/FontEditPlugin.dll
----------------------------------------
ImageEditPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/ImageEditPlugin.dll
----------------------------------------
LegacySpherePlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/LegacySpherePlugin.dll
----------------------------------------
MapEditPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/MapEditPlugin.dll
----------------------------------------
miniSphereGdkPlugin
    Assembly Version: 4.8.4.2270
    Win32 Version: 4.8.4.2270
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/miniSphereGdkPlugin.dll
----------------------------------------
ScriptEditPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/ScriptEditPlugin.dll
----------------------------------------
SpritesetEditPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/SpritesetEditPlugin.dll
----------------------------------------
TaskListPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/TaskListPlugin.dll
----------------------------------------
WindowstyleEditPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/Plugins/WindowstyleEditPlugin.dll
----------------------------------------
ObjectListView
    Assembly Version: 2.9.1.1072
    Win32 Version: 2.9.1.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/ObjectListView.DLL
----------------------------------------
Accessibility
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.2046.0 built by: NET47REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
ScintillaNET
    Assembly Version: 3.6.3.0
    Win32 Version: 3.6.3.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/ScintillaNET.DLL
----------------------------------------
SphereStudio.Vanilla
    Assembly Version: 0.0.0.0
    Win32 Version: 0.0.0.0
    CodeBase: file:///C:/Program%20Files/miniSphere/ide/SphereStudio.Vanilla.DLL
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.



I can't particularly make sense of it. I've noticed it comes up for quite a few things, but this is so far the only one that gave me the sads lol

Windows 10 Home Creator's Update, fresh install of miniSphere 4.8 w/ Sphere Studio.
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on September 09, 2017, 05:06:45 pm
Thanks, the spriteset editor is kind of buggy and tends to crash a lot.  I know I fixed one such bug very recently, but I thought that fix for that made it into mS 4.8.4?  Maybe not, or maybe you hit a different bug...

In any case I'm going to post a 4.8.5 patch later tonight so I'll put Studio through its paces and try to flush out any crash bugs.
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on September 09, 2017, 10:29:33 pm
On an unrelated note, .NET's dialog box for uncaught exceptions seems kind of mystical to me.  Normally when an exception is thrown, it unwinds the stack until it finds a catch{} block to handle it; if there is no catch{}, then the stack completely unwinds and the program crashes.  .NET apps instead show that dialog box which terminates the operation in progress but somehow the app keeps running.  I can't understand how that works--does the runtime just unwind the function that threw the exception?  And if so, what gets returned to the caller?  By all means something like that should never work... and yet it does. :hushed: 
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on September 10, 2017, 12:17:22 am
I fixed the bug.  "Set Delay" is only supposed to be enabled when you right-click an actual image frame (i.e. it's set per-image, not per direction), Sphere Studio mistakenly enabled it when clicking a direction header, and then clicking it causes an error because nothing is actually selected.

Fix is in 4.8.5.  Let me know if you find any other issues.
Title: Re: The Sphere Studio v1.2.1
Post by: Eggbertx on September 10, 2017, 12:22:13 am
On an unrelated note, .NET's dialog box for uncaught exceptions seems kind of mystical to me.  Normally when an exception is thrown, it unwinds the stack until it finds a catch{} block to handle it; if there is no catch{}, then the stack completely unwinds and the program crashes.  .NET apps instead show that dialog box which terminates the operation in progress but somehow the app keeps running.  I can't understand how that works--does the runtime just unwind the function that threw the exception?  And if so, what gets returned to the caller?  By all means something like that should never work... and yet it does. :hushed: 
It could be some kind of threading thing, something in .NET that isn't exposed to a program developer.
Title: Re: The Sphere Studio v1.2.1
Post by: Miscreant on September 18, 2017, 10:51:39 am
Unselected High Priority items on the task list seem a little difficult to read in both Light & Dark... Has anyone else found that?
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on September 18, 2017, 10:53:53 am
Hm, it doesn't seem to adapt well to the dark theme.  I'll have to fix that (along with a laundry list of other bugs :P)
Title: Re: The Sphere Studio v1.2.1
Post by: Eggbertx on September 18, 2017, 02:55:45 pm
Instead of changing the background color based on priority, why don't you create an icon for each?
Title: Re: The Sphere Studio v1.2.1
Post by: Miscreant on September 19, 2017, 09:36:11 am
Instead of changing the background color based on priority, why don't you create an icon for each?

If I may suggest:
Title: Re: The Sphere Studio v1.2.1
Post by: DaVince on September 19, 2017, 10:19:43 am
I like that a lot more - the gray font colors just *really* don't work well.
Title: Re: The Sphere Studio v1.2.1
Post by: Miscreant on September 19, 2017, 11:03:54 am
That was just a quick mockup I did. It does improve the readability of the Task List. Another thought would be to keep it the way it currently is and just darken the font some.
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on September 19, 2017, 11:06:22 am
Ideally the colors should be more subtle.  I don't want to do icons-only because then the high- and low-priority tasks don't have enough to differentiate them.  An item with a red background just screams "do this next!" that's lost with the icons.  It's just that it's not very readable right now...
Title: Re: The Sphere Studio v1.2.1
Post by: DaVince on September 19, 2017, 12:43:34 pm
In that case, making the text itself fully black would be the way to go. And decreasing the saturation of the background on the finished tasks.
Title: Re: The Sphere Studio v1.2.1
Post by: Miscreant on September 20, 2017, 12:17:50 am
I've also noticed that there are no tile numbers (eg 0/10) or pixel(x,y) (like in 1.5) in the tile/map editor. Was this done purposely or perhaps an oversight?

For me, Tile numbers in particular are extremely useful with Get/SetTile().
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on November 01, 2017, 07:22:10 pm
So I just tried to get Sphere Studio running on Linux Mono again, it flashed the window for a split second but then I got this:
Code: [Select]
fatcerberus@pigcult-vm:~/Desktop/sphere-studio$ sudo mono "Sphere Studio.exe"
SendMessage (62914598, 0x101f, (nil), (nil))
SendMessage (62914598, 0x1003, 0x3, (nil))
SendMessage (62914598, 0x109b, (nil), 0x7ffeaa5bf250)
SendMessage (62914598, 0x1036, 0x2000002, (nil))
SendMessage (62914598, 0x1027, (nil), (nil))
X11 Error encountered:
  Error: BadMatch (invalid parameter attributes)
  Request:     12 (0)
  Resource ID: 0x3C0001F
  Serial:      5655
  Hwnd:        Hwnd, Mapped:True ClientWindow:0x3C00020, WholeWindow:0x3C0001F, Zombie=False, Parent:[<null>]
  Control:     WeifenLuo.WinFormsUI.Docking.DockPanel, BorderStyle: None  at System.Environment.get_StackTrace () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.XplatUIX11.HandleError (IntPtr display, System.Windows.Forms.XErrorEvent& error_event) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.XplatUIX11.XTranslateCoordinates (IntPtr , IntPtr , IntPtr , Int32 , Int32 , System.Int32& , System.Int32& , System.IntPtr& ) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.XplatUIX11.ClientToScreen (IntPtr handle, System.Int32& x, System.Int32& y) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.XplatUI.ClientToScreen (IntPtr handle, System.Int32& x, System.Int32& y) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.PointToScreen (Point p) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.RectangleToScreen (Rectangle r) [0x00000] in <filename unknown>:0
  at WeifenLuo.WinFormsUI.Docking.DockPanel.GetAutoHideWindowBounds (Rectangle rectAutoHideWindow) [0x00000] in <filename unknown>:0
  at WeifenLuo.WinFormsUI.Docking.DockPanel.OnLayout (System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.PerformLayout (System.Windows.Forms.Control affectedControl, System.String affectedProperty) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ScrollableControl.OnVisibleChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at WeifenLuo.WinFormsUI.Docking.DockPanel.OnVisibleChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.OnParentVisibleChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.OnVisibleChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ScrollableControl.OnVisibleChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.OnVisibleChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.SetVisibleCore (Boolean value) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.SetVisibleCore (Boolean value) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.set_Visible (Boolean value) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Application.RunLoop (Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext context) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x00000] in <filename unknown>:0
  at SphereStudio.Ide.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0

System.EntryPointNotFoundException: ShowWindow
  at (wrapper managed-to-native) BrightIdeasSoftware.NativeMethods:ShowWindow (intptr,int)
  at BrightIdeasSoftware.NativeMethods.ShowWithoutActivate (IWin32Window win) <0x40bb31c0 + 0x00023> in <filename unknown>:0
  at BrightIdeasSoftware.GlassPanelForm..ctor () <0x40bb27c0 + 0x0017f> in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) BrightIdeasSoftware.GlassPanelForm:.ctor ()
  at BrightIdeasSoftware.ObjectListView.ShowOverlays () <0x40bb2100 + 0x000e3> in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.HandlePaint (System.Windows.Forms.Message& m) <0x40bb2080 + 0x00036> in <filename unknown>:0
  at BrightIdeasSoftware.ObjectListView.WndProc (System.Windows.Forms.Message& m) <0x40b3b220 + 0x00153> in <filename unknown>:0
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) <0x414ee940 + 0x00024> in <filename unknown>:0
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) <0x414ee900 + 0x00036> in <filename unknown>:0
  at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) <0x414ed390 + 0x0031c> in <filename unknown>:0

Also for some reason I had to run mono with sudo otherwise it gave me an error upon trying to access the registry.  Kind of weird.  Also strange is how the error I get is always different every time I revisit this...
Title: Re: The Sphere Studio v1.2.1
Post by: Fat Cerberus on November 01, 2017, 07:35:20 pm
Trying with Wine gave me a different error:
Code: [Select]
Unhandled Exception:
System.TypeLoadException: Could not load type 'System.WeakReference`1' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
  at SphereStudio.UI.DialogHeader..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) SphereStudio.UI.DialogHeader:.ctor ()
  at SphereStudio.Ide.BuiltIns.IdeSettingsPage.InitializeComponent () [0x00000] in <filename unknown>:0
  at SphereStudio.Ide.BuiltIns.IdeSettingsPage..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) SphereStudio.Ide.BuiltIns.IdeSettingsPage:.ctor ()
  at SphereStudio.Ide.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type 'System.WeakReference`1' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
  at SphereStudio.UI.DialogHeader..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) SphereStudio.UI.DialogHeader:.ctor ()
  at SphereStudio.Ide.BuiltIns.IdeSettingsPage.InitializeComponent () [0x00000] in <filename unknown>:0
  at SphereStudio.Ide.BuiltIns.IdeSettingsPage..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) SphereStudio.Ide.BuiltIns.IdeSettingsPage:.ctor ()
  at SphereStudio.Ide.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0

WeakReference has existed since .NET 1.1 so no idea what's going on there.
Title: Re: The Sphere Studio v1.2.1
Post by: DaVince on November 02, 2017, 04:14:11 pm
Quote
Also for some reason I had to run mono with sudo otherwise it gave me an error upon trying to access the registry.  Kind of weird.  Also strange is how the error I get is always different every time I revisit this...
Linux doesn't even have a registry, so it's even weirder that it DOES get past that point with sudo... Try not to run with sudo though. Graphical applications really shouldn't be run with sudo.

WeakReference seems to be part of mscorlib, which is something you have to explicitly install:
Code: [Select]
sudo apt install mono-complete

Edit: wait, that was with Wine? Weird, it's starting up just fine in Wine here.