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.

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.

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

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!

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

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?

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

@Lord English: You could use this in your plugin and resolve the file paths for packaging:

Code: (javascript) [Select]

PluginManager.IDE.CurrentGame.RootPath

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

Sure, add it in!

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.

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.

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

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.

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

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.