Skip to main content

News

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

0 Members and 4 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #450
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)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Radnen's Sphere Studio v1.1.7.0
Reply #451
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #452
Huh.  That's weird.  Nothing odd in that folder that might be tripping it up?
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Radnen's Sphere Studio v1.1.7.0
Reply #453
http://pastebin.com/QYbWi4zs
Here's an output of ls -R games

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #454
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. :(
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Radnen's Sphere Studio v1.1.7.0
Reply #455
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?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #456
That's the default folder by design.  Studio will always look there for projects regardless of what custom paths you have set.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Radnen's Sphere Studio v1.1.7.0
Reply #457
So now that you have it fixed in the repo, how long will it be before it's released?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #458
Officially this is Radnen's project, but I'll bundle a fixed version with minisphere 1.7.2 in a day or so.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Radnen's Sphere Studio v1.1.7.0
Reply #459
Dammit, putting it in ~\Documents\Sphere Studio\Projects still triggers the error

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #460
Hm, only thing I can think of is a corrupt game.sgm file...
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #461
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. ;)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.1.7.0
Reply #462
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!
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #463
<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.
  • Last Edit: August 15, 2015, 01:50:28 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.1.7.0
Reply #464

<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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here