next »

[Guest]

Caps lock is activated.

[Crashtour99]

Ok, so I'm working on what should hopefully be the last of the item ASM stuffs for my little project.  Hopefully this post won't be excessively long, and I can convey my idea/question properly.

Basically I want to add some custom code that runs whenever missiles/supermissiles/powerbombs are used.  Powerbombs I think won't be a problem as I found a couple of codes that run only once per usage of the item.  However missiles and super missiles are a bit different.  They share 4 unique codes between them that run every time you shoot.

(At the bottom of this post a text file is attached that shows all the breakpoints I found, so that should help understanding this next part.)

At $90/BF2D (one of the 4 shared codes) the Y value seems linked to the A value @ $90/C4EC which is STA $09D2  [$90:09D2]  (Currently selected status bar item:  1 for missile, 2 for super missile, 3 for powerbombs) so it seems like a good place to hijack the code.  The question is, once I jump to my custom code, do I do something like LDA #$000X (x= 1 or 2 for M/SM) and CPY, then BEQ to separate the custom codes for missiles/supers?

[P.JBoy]

What I'd do is hi-jack the first routine in that file.  It'd branch to your custom code just after store the value to $09D2.  The best way to jump to the code corresponding to the selected item would be to have a list of pointers, you'd multiply the value of $09D2 by 2, and do an indexed jump to it:

Code:

org FREESPACE
PHA ; PHX ; PHP
ASL A
TAX
JSR (POINTER_LIST, X)
PLP ; PLX ; PLA
// {replaced instruction used for hi-jacking}
RTS

POINTER_LIST:
dw BRANCH_NONE, BRANCH_MISSILES, BRANCH_SMISSILES, BRANCH_PBOMBS, BRANCH_GRAPPLE, BRANCH_XRAY

BRANCH_NONE:
// {code}
RTS

BRANCH_MISSILES:
// {code}
RTS

BRANCH_SMISSILES:
// {code}
RTS

BRANCH_PBOMBS:
// {code}
RTS

BRANCH_GRAPPLE:
// {code}
RTS

BRANCH_XRAY:
// {code}
RTS

[Crashtour99]

Damn it damn it damn it.....    

So I worked up a little patch that I think might work, but for some reason xkas is flaking out on me and every time I try to run it, it crashes.  When I try to use the GUI executable an error window pops up saying something about the .NET framework not having access, and when I try to use the command line to run it, it says it encountered a problem and needs to close (gives no description of what the problem is).  Tried redownloading xkas, and same thing.  I noticed however that about a month ago .NET was updated, so maybe that's it?  

Edit:  Just removed the last updates to .NET and it still doesn't work...    grrrrrr....
Edit2:  Just rolled .NET back to when I know it was working, and it's still giving the same damn error...    

[P.JBoy]

It crashes?  What do you mean?

[Crashtour99]

I figure it's easiest to do it this way...

(click to show/hide)

*when the .asm and rom are in the same folder with xkas*



*when they're in different folders*

And when I try it from the command line, it brings up a different Microsoft error window that doesn't give any description of what's wrong, it just says the "program encountered a problem and needs to close".

[P.JBoy]

Hm, not sure what your error may be, unless it's a Vista or 7 thing

[Zhs2]

Xkas has a GUI?

Either way, it doesn't look like we're going to get much out of this without a more verbose error message on xkas' part. Try command line only, maybe checking and double checking your ASM file to make sure that everything is bug-free? Maybe send a copy to someone that you trust and is computer savvy and see if they get the same problem?

[snarfblam]

With the command line version, after it says the program encountered an error and needs to close it should output a stack trace, or at least some error data, in the console. (You won't see it if the console closes immediately, or isn't shown, as might be the case with a script or batch file.)

Looking at that, all one could say is that xkas is having a problem redirecting the output from a command line program. Are the command line and GUI versions both the same executable file? (If the GUI and command-line are separate executables, the GUI could be having this error when it tries to read the output from the command-line executable if the command-line executable fails for some reason, so the error output from the command-line version could be helpful.) FYI, this is coming from someone who has never used xkas.

[Crashtour99]

As far as I know, the GUI version uses the command line version.  It just makes it so that you don't have to go into the command line and type stuff.
Hmmm...  After poking around the error window that comes up when using the command line, I found this...

(click to show/hide)

There are 22 "modules" in it's report, and modules 2-22 are various .dll files.
After that it lists a couple of threads with a shit ton of hex (I'm guessing this is the stack trace?).
It also included the file I attached at the bottom...

The GUI version is something that I found on SMWCentral, made by someone called NoobishNoobsicle.  I was using it for all my .asm patching, but for some reason when I tried to use it this time it won't work.

Edit And now, I feel like a total idiot, because I just tried it with the .asm patches I made that I know work fine, and they still work fine without crashing xkas...  So apparently there's something horribly wrong with whatever code I was trying to write.

[snarfblam]

All that hex and module garbage isn't particularly useful. Also, I was asking if the GUI was a separate executable (i.e. a front end) because if so, there could a problem with a configuration/environment variable/your asm that is causing the command-line assembler to crash, which could very well result in the particular error window you posted. Hope you get it sorted out.

[Crashtour99]

Yeh, I didn't think it'd be much help, but I thought I'd post it just in case.

I'm not really sure exactly how it works, but when you download the GUI you basically get a readme.txt and the GUI.exe and that's it.  I've noticed that when the GUI fails/crashes it "produces" an xkas.exe, so I assume it's somehow embedded in the GUI, then self extracts when in use and auto deletes when it's done, so if it fails it doesn't get rid of the xkas.exe.  Usually when a patch fails it gives a specific error message about something being wrong in the .asm file, which is why I was so confounded by the complete crash of the program this time.  I was thinking it was a problem with my computer and not the .asm.

Thanks for the help guys.

[Crashtour99]

   It works flawlessly!   
Big thanks to you, P.JBoy.  I didn't quite do it how you said, but I wouldn't have been able to do it at all without your help.

Check it in action...

(click to show/hide)

http://www.youtube.com/watch?v=Lt7CCpulcOw

And as it turns out, having "lorom" at the start of your .asm file is kind of essential...  *facepalm*  That wasn't what was making xkas crash btw, but it didn't help either.