Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8506290 times) previous topic - next topic
0 Members and 10 Guests are viewing this topic.

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1005 –
If the error is in an embedded map script, it should be reporting the filename as something like Test.rmp:onEnter or Test.rmp:Entity1:Talk.  You mean it's not doing that?

Note that it doesn't (currently) show source code for embedded map scripts, although that may be possible to do.

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1006 –
Quote from: DaVince – on

The crash happened in "undefined:0", but at least the backtrace ensured it was clear it was in the map engine and exactly what line in the scripts started that map engine with which map. That is really useful. Thanks a ton for making this! :)

Edit: should say, though, if this could somehow report which line/script in the map file is doing that, that would be cool, because... the map it errored out on has like fifty entities.


I just realized, if it says "undefined:0" that means the error was thrown by a Sphere API (e.g. Abort()), not directly by the script.  That's something I need to fix before the final release: It should automatically select the next stack frame up if the error occurs in an API function (the API is throwing it on behalf of the game anyway).  For now if it drops you into "undefined:0" just enter the command "up" to switch to the function that actually caused the error.

And hey, no problem - A symbolic debugger is something I always wished Sphere had and the lack of one always held it back as serious game development tool for me.  Finally having it at my disposal is awesome--even more awesome because I wrote it. ;D

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1007 –
Quote from: Lord English – on

I just realized, if it says "undefined:0" that means the error was thrown by a Sphere API (e.g. Abort()), not directly by the script.  That's something I need to fix before the final release: It should automatically select the next stack frame up if the error occurs in an API function (the API is throwing it on behalf of the game anyway).  For now if it drops you into "undefined:0" just enter the command "up" to switch to the function that actually caused the error.

Oh! You're right! I didn't see it at all, but it *does* say this:

Code: [Select]
FATAL UNCAUGHT - TypeError: number required, found '0' (stack index 1)
   at: [nutcracker1 : queued script]:1
=> # 0: SetPersonFrame() at undefined:0
'undefined': source file could not be located.


I guess what threw me off is that it's not giving the map file name, so I wasn't looking properly for the "nutcracker : queued script" bit.

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1008 –
Dammit, I think I'm going to have to bite the bullet in minisphere 3.0 and allow API functions to accept 0/1 in place of true/false.  Quite a few Sphere games seem to do that but minisphere doesn't like it because it's not actually a JS boolean value.  I suspect that's the cause of your error.

The reason it doesn't show the map file name is because at the time the script is queued (using QueuePersonScript) only the person name is known.  I could probably fix that by tracking which map transient persons are created for.

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1009 –
Hm, on second look it actually looks like error is that the game passed a string for the second argument to SetPersonFrame() which expects a number in that slot.  Since this is based on Kekfa's Revenge code I shouldn't really be surprised. :P

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1010 –
Next (pre)release of minisphere I want to add the ability to send source to the debugger directly from the running game so that:


  • SSJ doesn't need a local matching copy of the source, eventually enabling easy remote debugging.  This is unsupported at present because the requirement for local source makes it unwieldy.  If the source doesn't match, your line numbers will be off which is very confusing!

  • Embedded map scripts without a physical script file can still be debugged with source code present.  So this way if an error occurs with an NPC script you get to see the line of code that caused it.

  • SSJ could see the source for system scripts, e.g. miniRT.  Right now the debugger doesn't necessarily know where the engine is so it can't easily load them.  Handing off source loading duty to minisphere would eliminate the issue entirely (since the engine has to know where all the code is by definition).



My goal is to have minisphere 3.0 go gold on the first anniversary of the minisphere 1.0 release, March 28.  So that gives me about a month.  Looks like 2016 will be the year of the Sphere debugger! :)

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1011 –
@DaVince
I implemented source download in SSJ (after solving a nasty segfault mentioned in the Programming board that ruined my night...), and using it, proceeded to track down the cause of your KR crashes:

Code: [Select]

C:\Users\fatce\Documents\Sphere Studio\Projects>ssj kr
SSJ 3.0a3 minisphere Console Debugger (x64)
a powerful JavaScript debugger for minisphere
(c) 2016 Fat Cerberus

starting C:/Users/fatce/Documents/Sphere Studio/Projects/kr/... OK.
connecting to 127.0.0.1:1208... OK.
verifying... OK.
querying target... OK.
    game title: Kefka's Revenge
    author: KRTeam

=> # 0: eval() at scripts/game.js:12
12: GetSystemFont().drawText(15,10,"LOADING...");

scripts/game.js:12 eval()
(ssj) c
FATAL UNCAUGHT - TypeError: number required, found '83' (stack index 1)
    at: maps/Aresidence1.rmp/onEnter:2
=> # 1: global() at maps/Aresidence1.rmp/onEnter:2
2: SetPersonX('daughterslaughter', '83');

maps/Aresidence1.rmp/onEnter:2 global()
(ssj) l
      1: dispTown = "Family home";
=>    2: SetPersonX('daughterslaughter', '83');
      3: SetPersonX('workdude', '277');
      4: SetPersonY('workdude', '212');
      5: SetPersonDirection('workdude', 'west');
      6: IgnorePersonObstructions('kid', true);


Unfortunately KR does things like this a lot, which is what makes it so hard to support.  But now you can see source for map scripts directly in the debugger, which is awesome!

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1012 –
Wow, thanks! I really don't think you needed to 'fix' this, since it would kinda promote bad coding practice, but... hey, you did it! :P

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1013 –
I didn't fix the KR bug if that's what you mean - I mostly just wanted to track down the cause since I wasn't able to do this even with the Sphere Studio debugger.  Since the classic map engine is still supported in minisphere, it was kind of dumb that you couldn't see map code in the debugger.  Now you can!

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1014 –
It even works for scripts set up at runtime (e.g. update scripts), for example here it shows the GenCommands stub installed by analogue.js:

Code: [Select]

src/main.js:53 game()
(ssj) w
   # 0: global() at maps/Testville.rmp/maggie/genCommands:1
1: analogue.runPersonEvent(GetCurrentMap(), 'maggie', 'generator');

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1015 –
Quote from: Lord English – on

I didn't fix the KR bug if that's what you mean - I mostly just wanted to track down the cause since I wasn't able to do this even with the Sphere Studio debugger.  Since the classic map engine is still supported in minisphere, it was kind of dumb that you couldn't see map code in the debugger.  Now you can!

Ah, okay! That makes a LOT more sense. In any case, this just makes it more powerful!

Re: minisphere 3.0b2 (stable: 2.1.6)

Reply #1016 –
Another useful feature I added is that if execution stops in a system call, SSJ will automatically select the next stack frame up that actually contains JS code.  This avoids the need to do "up" first.

Re: minisphere 3.0b3 (stable: 2.1.6)

Reply #1017 –
Just posted another beta, minisphere 3.0b3.  SSJ has a brand-new feature: It pulls source code for the game being debugged directly from minisphere.  This means you can debug games, even those packaged as SPKs, without having access to the original source tree: So long as the scripts weren't minified or otherwise mangled before being compressed, you can now debug any Sphere game past, present and future.

I also enhanced the output of SSJ's "examine" command to make it more useful this release: It now shows property attributes for all properties and produces a nice listing like Unix ls -l:

Code: [Select]

scripts/main.js:30 game()
ssj: x GetGameManifest()
ewc- name                "Spectacles: Bruce's Story"
ewc- author              "Fat Cerberus"
ewc- summary             "Follow Scott Starcross in his quest to stop the Primus."
ewc- resolution          "320x240"
ewc- script              "scripts/main.js"
ewc- minimumPlatform     {obj:"00000187b9161c10h"}
ewc- frameRate           60
ewc- sceneRenderPriority 99
ewc- logPath             "~usr/Spectacles Saga/Console Log.txt"
ewc- consoleBuffer       1000
ewc- consoleLines        10
ewc- disableAnimation    false
ewc- disableBattles      false
ewc- disableSplash       true
ewc- disableTitleScreen  true
ewc- directory           "C:/src/spectacles-i/dist/"


That's "ewc" for "Enumerable, Writable, Configurable".  The last slot which is clear here is "a" for Accessor (a property with a getter/setter).  All properties are listed, even non-enumerable ones.  This is in contrast to eval which only lists enumerable properties.  If you do examine global be prepared for an absolutely massive listing!

Re: minisphere 3.0b3 (stable: 2.1.6)

Reply #1018 –
@DaVince: Have you tried the new beta yet?  SSJ is much more useful now. :) (there might be a few crashes which I've since fixed in the git repo)

Re: minisphere 3.0b3 (stable: 2.1.6)

Reply #1019 –
Not yet, I haven't really had much time to dedicate to game dev lately! Also not sure where/how I would use all this shiny new stuff, will definitely have to read the manpages and try things out.

To be honest I'm not used to debuggers in general, so it's going to take a bit for me to get used to it all. :)