The Sphere Studio v1.2.1

Topic: The Sphere Studio v1.2.1 (Read 2624885 times) previous topic - next topic

0 Members and 4 Guests are viewing this topic.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #450 – 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)

Re: Radnen's Sphere Studio v1.1.7.0

Reply #451 – 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

Re: Radnen's Sphere Studio v1.1.7.0

Reply #452 – August 14, 2015, 03:37:52 pm

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

Re: Radnen's Sphere Studio v1.1.7.0

Reply #453 – August 14, 2015, 03:40:42 pm

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

Re: Radnen's Sphere Studio v1.1.7.0

Reply #454 – 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.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #455 – 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?

Re: Radnen's Sphere Studio v1.1.7.0

Reply #456 – 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.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #457 – 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?

Re: Radnen's Sphere Studio v1.1.7.0

Reply #458 – 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.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #459 – August 14, 2015, 08:45:36 pm

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

Re: Radnen's Sphere Studio v1.1.7.0

Reply #460 – August 14, 2015, 08:47:11 pm

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

Re: Radnen's Sphere Studio v1.1.7.0

Reply #461 – 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.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #462 – 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!

Re: Radnen's Sphere Studio v1.1.7.0

Reply #463 – 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.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #464 – August 15, 2015, 01:53:56 am

Quote from: Lord English – 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.

I guess you're doing that for consistency with <game>.ssproj, then. Okay.

Quote from: Lord English – on August 15, 2015, 01:45:47 am

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

Quote from: Lord English – on August 15, 2015, 01:45:47 am

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