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)

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

Huh.  That's weird.  Nothing odd in that folder that might be tripping it up?

http://pastebin.com/QYbWi4zs
Here's an output of ls -R games

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.

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?

That's the default folder by design.  Studio will always look there for projects regardless of what custom paths you have set.

So now that you have it fixed in the repo, how long will it be before it's released?

Officially this is Radnen's project, but I'll bundle a fixed version with minisphere 1.7.2 in a day or so.

Dammit, putting it in ~\Documents\Sphere Studio\Projects still triggers the error

Hm, only thing I can think of is a corrupt game.sgm file...

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.

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!

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

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