Project64 Debugger « 1 ... 3 4 5 6 7 »
Users browsing this thread: 1 Guest(s)

06: Mario Upset 
Well, that fixed that problem. But now when I try to run it I get this: (See Attachment again)

I really wish this would work for me, but I guess that's what I get for running an outdated-but-better-than-any-later-versions version of Windows Tongue


Attached Files    
Quote:A word fitly spoken is like apples of gold in pictures of silver.
  --Proverbs 25:11


And that's what I get for not checking the "Requirements" sections on Microsoft's documentation Tongue . I don't intend on breaking XP support. It looks like there are still a few more of those "Ex" function calls in the script system code that will need to be replaced before this is fixed.
My threads are now being maintained here

Great! Big Grin On behalf of all XP users of this community, I thank you. Wink
Quote:A word fitly spoken is like apples of gold in pictures of silver.
  --Proverbs 25:11


with the scripting stuff, how would I unsubscribe from an event?

Callback registration now returns an ID and events.remove can be used on it, e.g.:
Code:

var id = events.onexec(0x80000180, function()
{
    // only invokes once
    console.log('hello');
    events.remove(id);
})

New build: http://shygoo.net/pj64d/Project64d%205-15-17.exe
(This post was last modified: 15-05-2017, 11:17 AM by shygoo.)
My threads are now being maintained here

neat Big Grin

I was also wondering how the server/socket stuff works a little better. Like, is there a way to connect to pj64 via chrome?

Yep it's possible, however there's no HTTP stuff built in at the moment so it has to be implemented within the script. I made some example code available at the bottom of this post: http://origami64.net/showthread.php?tid=549&pid=6749#pid6749

Edit: Attached the files for convenience
(This post was last modified: 15-05-2017, 11:45 AM by shygoo.)


Attached Files
Size: 2.35 KB / Downloads: 46 .htm   sm64-collisions.htm

Size: 982 bytes / Downloads: 46 .js   sm64-collisions.js

My threads are now being maintained here

(16-01-2017, 09:29 PM)shygoo Wrote:
(28-12-2016, 10:56 PM)mzxrules Wrote:
Overlay files


I glanced over this and if I understand correctly, this mapping is done entirely within the game and has nothing to do with hardware, right? I don't plan on supporting game-specific things but I could add some sort of pseudo-address field to accommodate. Another option would be to maintain a custom symbols table with a script that reads the specifics of the overlay system for mapping. At the moment the script API doesn't support any GUI stuff per se, but any relevant data can be sent between the game and an external program over a socket.

Example of an external gui program w/socket
https://github.com/shygoo/project64/commit/48a5e1357515302f40e0287bd6c99c18bd90bf2e#diff-85c421e96300341e1bddd673935a431f




This is awesome, how simple would it be to do this in OoT? I can see many people liking something like it for the Haunted Wasteland section, you should be able to colorize the polygons that are safe and which ones void out.

Hey, this is a really great project! I have been using Nemu, but gave this a try today and took down some notes as I thought of them.

​Symbol viewer
  • ​Some values are most meaningful to see in hex, so it would be nice if there was some means of showing either hex only or decimal and hex for symbols.
  • ​Some values are enum-like, so it would be pretty great to be able to specify a mapping like "0='Mario',1='Luigi',2='Peach',etc." and have the symbol viewer show something like 0 (Mario).
  • ​I found myself wishing there was an "address" type, but maybe just being able to configure hex view of "data" would be sufficient.
  • ​Maybe a bool type? Not very important, since 0/1 is obvious.
  • ​I tend to pick the wrong type a lot, and I wish there was a way to edit the symbols beyond just editing the .sym file.
  • ​A lot of symbols may only make sense when certain conditions are met. It would be great to have a Symbols API that could allow for dynamically adding/removing symbols. I'd imagine these would never save to the .sym file, since there would be a script instead that would manage them.

​Command viewer
  • ​Really missing Nemu's Step Over functionality, although the "Run until" functionality is somewhat similar.
  • ​Tooltips on the instructions (similar to Nemu) could be really helpful.
  • ​I may adjust to it, but the register fields seem really small.

​Memory viewer

Overall I think the memory viewer is the area which could benefit the most from enhancements. I experience a lot of crashes from this window. (I think it is mostly original from PJ64 so I don't blame you!)
  • ​Here, and generally anywhere, it would be nice to have a "Go to address" option when right clicking on something that looks like an address.
  • ​Mousewheel scrolling
  • ​Would be nice to resize larger

​General
  • ​If it would help performance, I wouldn't mind the option to disable automatic refresh (especially in the memory viewer) in favor of a manual refresh button.

I'm looking forward to trying out the JS API soon!

Is there anyway I could use this to track memory it's displaying. And tell the tool to ignore them in display. To make it easy to find the memory path I'm looking for?

Sorry it's hard to explain what I'm trying to say lol

Project64 Debugger « 1 ... 3 4 5 6 7 »
Users browsing this thread: 1 Guest(s)