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.

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

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.

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.

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.

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?

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.

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

Not exactly an improvement.

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.

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.

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.

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.

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?

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?

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.