First post here...long time retro gamer, active member over at Knobbe.org (for Tecmo Super Bowl). Howdy folks...
Couple of friends and I decided to start up an RBI league, and I had written a few extractor classes for Tecmo before, so I thought I'd take a stab at writing one for RBI. I have my first version of it done (passed my initial testing, but there could be bugs). I figured I'd offer it up here if anyone wants a copy...be glad to help out the community.
Moving on to my question...I love Nightwulf's editor, but since I'm sort of OCD, I'm always afraid something will go offline. I was hoping possibly to either write my own editor by getting at some of the hex locations from nightwulf's editor) or even better having him lend me his code so I can at least have a working copy in case his ever goes away. Even if his promised to stay up forever, I'm still a freak, and like to have a hard copy of it. I've emailed Wulf and Gantry about this, but I'm not sure how often those guys check their email (or spam boxes) from people they don't know.
So, I then heard that DBatche's editor is a standalone win app that accomplishes most of what Wulf's does. DB's link is down and I can't find the editor anywhere. Anyone have a copy of it? Otherwise, if Wulf still reads this, I'd be happy to help with writing a windows application if I had all the info for it, such as hex locations for all the hacks and whatnot.
Hit me up if you'd like some assistance (I saw an old thread with you talking about this). Thanks for keeping this game alive folks, hope to hear from some of you soon, regarding the editor, or my extractor. Peace!
not sure if this will help, but i think i downloaded this sometime back in 2002. it's called "rbi manager" ...it's probably dbatches??
Really? I thought DBatche's was separate from the RBI manager...the RBI Manager one pukes out on anything but the overstuffed version, and it seems once I export the overstuffed from wulf's site, even without making an edit, the RBIM closes as soon as I try to load it.
Can someone confirm if RBIM is DBatch's work?
Man, if I can get hooked up with the right person, I could take everything in wulf's site and put it into a winapp, and that would be groovy.
i'm not sure if what i posted was dbatch's. now that you mention it, i do remember there being two editors around that time. (that was before i discovered this site and before nightwulf creted his online ed. )
i think i kept rbi manager over the other editor because there was something about RBIM that was better just from a player/team editing perspective. but who knows, that was a long time ago. hopefully someone's got dbatch's if mine isn't it, so you can have your choice.
RBIM I think edits in real-life stats...meaning 74MPH fastball vs. a numeric indicator from 0-255...
that's probably one reason why i liked it better. i don't know code or understand hex or antyhing.
did you notice the colors in RBIM, are those different than in nightwulf's editor? just curious.
oh, and can you post your stat extractor? does it really recognize actual hits and not get confused by a batter/runner trying to stretch a single into a double and getting thrown out and then the comp not recognizing a hit? or does it just pull the stats from the end game screen?
I'll post it when I get home from work. It only pulls in what an unpatched game is capable of at this point. Somewhere down the line if I teach myself the NES assembly, I could potentially have it track individual stats, but please note this won't be anytime soon. We have a guy in the Tecmo community who added 4 teams to the original rom and does a lot of patching and hacking, but he's tough to get hold of, so for now, it's only gonna be good for what the game allows, e.g., stuff from the end of the game...
Better than nothing for now, right?
yes or no, sadly.
hr's, walks and strikeouts are probably the only things handled accurately by the game. maybe not even hr's because of bad throws allowing inside-the-park homeruns to be incorrectly scored some of the time (dpending on timing and result of the throw). you might be able to switch AB's to plate appearances to be correct. i think that's it.
I think DBatch's editor is separate, but like TBG, I've never actually seen it, so I can't tell you what it can and can't do.
The stat extractor sounds cool, although I don't know how useful everyone would find it - for our fantasy leagues (there aren't much for live leagues like I believe TSB has, at least not that are run through this forum), someone actually watches the game and creates a full play-by-play. It's more arduous, but our commissioners have been willing to do it.
Individual stat extraction would be a bitch - besides the limitations TBG mentioned where the game just scores things wrong, the fact that the game doesn't track individual stats means that you'd have to have the extractor monitoring the RAM in real time, storing the current batter and runners, then reading the stored box score data to see what got incremented.
It's not something I'm capable of now, but I know a guy who is more than capable. He successfully added a hack to TSB that stored tackles done by individual players...a stat that isn't supported by the game out of the box. He created page variables that would increment during the game and wrote the values to empty spots on the rom. Didn't sound too hard for a guy like him to accomplish.
Me, I don't know assembly, yet.
As for my extractor's usability, you might be right. Just thought I'd offer it up anyways...TSB community has been good to me, so it's in my nature to give back and return the favor, whether it be them or a different set of enthusiasts for a different game...
I'd really like to make Nightwulf's online editor into a win app though. That'd be fun...
Unfortunately, there is no one holy document that plainly lists everything we uncovered. I did see your e-mail and spent some time perusing a couple hundred files in my old rbi/ directory, but it's all over the map. Equally as unfortunate, it's not as simple as just sending "the code." The editor is a complex application in Perl (server-side) and Javascript (client-side), and it's also all over the map. I'm sorry to say that I'm terrible about commenting code intended for my own use, and combined with the chaotic nature of Perl itself, I don't know how much use trying to decipher all of that would be.
At one point I did intend to clean the code up and make it more modular, for the purpose of creating an RBI-editing framework that could be expanded to include editing capabilities for several RBI games while sharing common functionality. That project didn't go far, but I did come up with a sparsely-commented Perl module for ROM parsing and functions to read/change most pertinent data. It's unfinished and I never used it outside of testing, but it should give you a start. The file is attached. It's not quite as concise as the editor's backend, so it should be more useful for pulling hex addresses and figuring out what to do with them.
The majority of the raw information is housed in these forums. I think there was a "RBI Rosetta Stone" thread that tried to manage all of this data. Failing that, you're in for a lot of searching. Found the thread I was looking for here (http://forums.dee-nee.com/index.php?topic=11729.0).
The hacks I wrote myself (long batting averages, long ERAs, long team names, per-pitcher batting) have no official documentation. I'll see what I can come up with.
This will help if you decide to tackle 6502 or dig up the guy who does.
Last one. This should give you something to work with on the editor-specific hacks ...
You are the man Nightwulf. I had resorted to doing binary compares of an original vs. a changed rom and found a bunch of stuff. This will help even more, so thanks. I was able to find some of the long batting averages and such with a binary compare, but this documentation is magnificent, and will save me a lot of that tedious work. Thanks so much for your generous offering of all the hard work you've done.
My only concern is that I'm locked into the 96k rom size because I did all my compares on that. I have a feeling the hex locations are in different spots on the other roms. Not that this is a huge deal, but it'd be cool to make it as flexible as yours was.
Sorry for all the emails nightwulf, I'm sure you were like, "who the eff is this dude!"
P.S. I had a late night and didn't get to my extractor to post it. Look for it tonight if you care.
Quote from: tecmoturd on 04/21/09, 06:41:32 AM
You are well hung Nightwulf. I'm man crushing on you...
Quote from: tecmoturd on 04/20/09, 05:09:21 PM
It's not something I'm capable of now, but I know a guy who is more than capable. He successfully added a hack to TSB that stored tackles done by individual players...a stat that isn't supported by the game out of the box. He created page variables that would increment during the game and wrote the values to empty spots on the rom. Didn't sound too hard for a guy like him to accomplish.
Wow, that's awesome, especially that it manages to store the data in the ROM - I was expecting something running separately that simply monitored the RAM of the emulator and displayed the data separately.
The whole "is it a hit?" thing would be really problematic to solve, although I'm sure there are ways of doing it, if you go to enough trouble - for example, to solve the problem where the game rules any out on the basepaths a non-hit, you could set a "hit" flag that is set once the batter and all runners hit the next base safely, and after that point the hit is not negated.
The hit/error thing would be the nastiest part of that try and fix, because some of it is just a judgment call. The simplest method would be to simply rule a play with an error a non-hit, but there a couple scenarios where that doesn't work - base hits to the outfield bobbled by the OF, bad throws from the outfield to third base.
I'm putting a lot of thought into this, considering I have no idea how to do any of it (well, I have vague ideas, but certainly not enough ambition to actually do it).
EARLY THROW BOP
You still have no evidence broiler...that only exists in your head.
Quote from: tecmoturd on 04/21/09, 06:41:32 AM
My only concern is that I'm locked into the 96k rom size because I did all my compares on that. I have a feeling the hex locations are in different spots on the other roms. Not that this is a huge deal, but it'd be cool to make it as flexible as yours was.
Don't be concerned. The only reason I added support for the "overstuffed" ROM (originally the editor would parse any RBI ROM but only output in 96k) was because there were one or two emulators that crashed with the 96k version. At this point in NES emulation, there's really no excuse for poor MMC3 handling by an emulator. If the emulator can't run the 96k ROM, it's the emulator's fault, not yours.
That said, it's really simple to handle all three, as you've probably gathered by now from the Perl module. Define an offset for
prg and
chr data to use while parsing the ROM and the numeric offsets stay the same. The same in reverse is true for writing it back.
I'd parse any format and only output in 96k. We just don't need these gargantuan poorly-designed ROMs running around for no reason other than their user wants to use an emulator that is fundamentally broken.
Quote from: BeefMaster on 04/21/09, 10:59:42 AM
Wow, that's awesome, especially that it manages to store the data in the ROM - I was expecting something running separately that simply monitored the RAM of the emulator and displayed the data separately.
The whole "is it a hit?" thing would be really problematic to solve, although I'm sure there are ways of doing it, if you go to enough trouble - for example, to solve the problem where the game rules any out on the basepaths a non-hit, you could set a "hit" flag that is set once the batter and all runners hit the next base safely, and after that point the hit is not negated.
The hit/error thing would be the nastiest part of that try and fix, because some of it is just a judgment call. The simplest method would be to simply rule a play with an error a non-hit, but there a couple scenarios where that doesn't work - base hits to the outfield bobbled by the OF, bad throws from the outfield to third base.
I'm putting a lot of thought into this, considering I have no idea how to do any of it (well, I have vague ideas, but certainly not enough ambition to actually do it).
I really thought the way to go with this would be to have people playing in leagues send in a "movie" that most of the emulators can create. These movies are little more than a condensed list of all controller activity with a RAM snapshot at the start. Using that and the league ROM, software could then "replay" the game and calculate stats to a much higher degree than what's saved in RAM at "game over." I starting looking into this, but lost interest somewhere along the road ...
Good to know. Your code wasn't that hard to follow either, I did professional PHP development (and currently do C#) so the Perl translation was pretty easy to make...
Your idea for extracting ind. stats out of a movie is intriguing...far beyond my game hacking abilities at this time, but sounds interesting...
P.S. Nightwulf, do you know if the starting pitcher is stored somewhere in the final save state? I envision if it is it's an index of 0-3 or something like that...for our league we require different SP's for each series game, and it'd be cool to have this show up on our box score...
Glad to see this thread out there, as I too have been meaning to answer tecmoturd's email. Welcome and keep up with this work! Good to see some further development in this area...
Yes, sorry for hitting you from different angles, (email, PM, and posting on the forum). I just wasn't sure what method you guys would see, and I'm excited to take a break from Tecmo for a while and focus on my other favorite game.
Extractor available in first post. I tried to write some notes inside the header of the class...if anyone has any trouble or has issues, please find me on AIM and I'd be glad to walk you through it. There definitely could be errors, as this was written in about two evenings when I was up way later than I should have been :)
Quote from: tecmoturd on 04/21/09, 01:06:53 PM
P.S. Nightwulf, do you know if the starting pitcher is stored somewhere in the final save state? I envision if it is it's an index of 0-3 or something like that...for our league we require different SP's for each series game, and it'd be cool to have this show up on our box score...
Technically, no. The current "away" pitcher data is stored at
$0600-$060F, and the current "home" pitcher data at
$0610-$061F (RAM offsets, obviously). Once a new pitcher is brought in, the data at that location is overwritten.
That said -- the game does need to keep track of starting pitcher usage because they can't be used in consecutive games. I've not looked for it yet, but somewhere in RAM there must be a flag to indicate that a pitcher can't be used in the next game. Unfortunately, that still doesn't help you if the player chooses a relief pitcher to start.
Quote from: nightwulf on 04/21/09, 10:37:46 PM
Unfortunately, that still doesn't help you if the player chooses a relief pitcher to start.
Everyone is just against Attez here aren't they
Quote from: tecmoturd on 04/21/09, 09:28:41 PM
Yes, sorry for hitting you from different angles, (email, PM, and posting on the forum). I just wasn't sure what method you guys would see, and I'm excited to take a break from Tecmo for a while and focus on my other favorite game.
Please do, I am pretty bad with getting back to people and nightwulf isn't on as much anymore. So for something this RBI-relevant I'm glad you kept trying.
Quote from: Gantry on 04/21/09, 11:01:51 PM
Please do, I am pretty bad with getting back to people and nightwulf isn't on as much anymore. So for something this RBI-relevant I'm glad you kept trying.
Who said I'm not around? Maybe I just haven't had anything to say since August ...
So what's considered a RP then, anyone in the 2-4 spot? In our league, we require you to start a #1 or #2 for each game, so if we just had the index for the starting pitcher at the beginning of the game, I could display that on our box score. Not a huge deal, would just be cool...
the RP's are spot 3 and 4.
Awesome, perhaps what Nightwulf said would work, at least in our case. Maybe choosing a RP to start actually still puts that information in the rom, and the game ignores it if it isn't one of the SPs. That'd be ideal...
Quote from: tecmoturd on 04/22/09, 10:31:16 AM
Awesome, perhaps what Nightwulf said would work, at least in our case. Maybe choosing a RP to start actually still puts that information in the rom, and the game ignores it if it isn't one of the SPs. That'd be ideal...
It depends on if you use more than one of the two SPs in the same game - the "SPs can't pitch in consecutive games" rule applies to any appearance, not just a start, so if you bring one of your SPs in as a reliever, both of them would show up in the "already pitched" list (or be flagged, or however the game stores that data).
Our rule is only one SP per game...
Here's how the pitcher thing works. Watch the following values in RAM:
0x0640 - 0x064F (away team)
0x0650 - 0x065F (home team)
The whole 0x064x line stores the current batting lineup for the away team, and 0x065x for the home team. The 16 values correspond to the 16 players on the team. For example, if you start a game as the away team choosing the first pitcher (pitcher 0), your lineup would look like this:
0x0640> 01 02 03 04 05 06 07 08 00 00 00 00 09 00 00 00
Remember that team data in ROM is stored as the first eight players (the starters) followed by the four pinch hitters followed by the four pitchers. If you took out the first pitcher and picked the third (first reliever, pitcher 2), the lineup would change to:
0x0640> 01 02 03 04 05 06 07 08 00 00 00 00 FF 00 09 00
Note that the pitcher you just removed had his lineup spot changed to 0xFF. This is a flag value used to indicate that that player is no longer available.
So, in your end-game save states you can read those values to determine which pitchers were used and the current pitcher (as of the game end). If you restrict your league play to one starting pitcher, you can tell which one was used, but not when.
Incidentally, you can also tell which batters were taken out of the lineup and which pinch hitters were used, but again without any information about who replaced who or when.
Neato! I'll mess around with this...
I assume 09 = the active pitcher? So, am I correct in the following?
SP2, relieved at some point by RP2:
0x0640> 01 02 03 04 05 06 07 08 00 00 00 00 00 FF 00 09
SP2, pitched whole game
0x0640> 01 02 03 04 05 06 07 08 00 00 00 00 09 00 00 00 (or would it be xFF'd at game's end because he couldn't be used, even though he was never subbed out)
RP1, relieved by SP1
0x0640> 01 02 03 04 05 06 07 08 00 00 00 00 09 00 00 00 (would RP1 be xFF'd or x00'd)
I should really have you show me how you found this stuff...might be a good time to learn how to use that debugger. I was always interested in doing so, just never been brave enough, or had a kind soul to assist me.
Maybe I should explain this better. Those 16 bytes (0x0640-0x064F) represent the 16 players on the away team. Each byte's value can represent one of three things:
00: the player is not currently in use, and is available to use
01-09: the player is currently in use, and the number represents his place in the batting order
FF: the player has been used and can no longer be used
So ...
Quote from: tecmoturd on 04/23/09, 08:56:25 AM
I assume 09 = the active pitcher?
Usually. Technically 09 would represent the player currently batting ninth. That would be the active pitcher the vast majority of the time. The only problem that comes to mind is a walk-off home run by a pinch hitter in the ninth spot. I'll need to try that tonight.
Quote from: tecmoturd on 04/23/09, 08:56:25 AM
SP2, relieved at some point by RP2:
0x0640> 01 02 03 04 05 06 07 08 00 00 00 00 00 FF 00 09
Yes.
Quote from: tecmoturd on 04/23/09, 08:56:25 AM
SP2, pitched whole game
0x0640> 01 02 03 04 05 06 07 08 00 00 00 00 09 00 00 00 (or would it be xFF'd at game's end because he couldn't be used, even though he was never subbed out)
No. The above would be pitcher 0 (first starting pitcher) remaining in the whole game. It wouldn't be FF if he was active the entire game, but I'm sure you realize that after I gave an explanation that made more sense.
Quote from: tecmoturd on 04/23/09, 08:56:25 AM
RP1, relieved by SP1
0x0640> 01 02 03 04 05 06 07 08 00 00 00 00 09 00 00 00 (would RP1 be xFF'd or x00'd)
No. RP1 relieved by SP1 would look like this:
0x064C> 09 00 FF 00assuming no other pitchers were used.
Quote from: tecmoturd on 04/23/09, 08:56:25 AM
I should really have you show me how you found this stuff...might be a good time to learn how to use that debugger. I was always interested in doing so, just never been brave enough, or had a kind soul to assist me.
Step one is learning 6502.
That does make more sense. So to gather that SP1 was the starter:
09 00 00 00 (pitched the whole game)
or
FF in first slot and one of the remaining three slots would have the 09 (pitched and was subbed)
I also didn't realize that if you start an RP, he'd be unavailable to start the next game. Interesting...I learn so much about the game I never knew when I was a kid...
Thanks for the explanation...
Quote from: tecmoturd on 04/23/09, 11:30:06 AM
That does make more sense. So to gather that SP1 was the starter:
09 00 00 00 (pitched the whole game)
or
FF in first slot and one of the remaining three slots would have the 09 (pitched and was subbed)
Sure. To be specific, I'd say "0x064C is non-zero and 0x064D is zero." Pitcher 0 was used, pitcher 1 was not. Within the rules of your league (one SP per game), that would hold true.
Quote from: tecmoturd on 04/23/09, 11:30:06 AM
I also didn't realize that if you start an RP, he'd be unavailable to start the next game. Interesting...I learn so much about the game I never knew when I was a kid...
The RPs can always start. By "not available," I mean available within that game, not the series. A used RP is not available to pitch in a single game once they've been used, but they can always pitch the next.
I was just about to say, what if you subbed in the second SP...but you're right, that violates our league rules.
Just for educational purposes, wouldn't that situation look like:
FF 09 00 00
This will be good. Now I can display the SP for the game on the box score. Booyah.
Quote from: tecmoturd on 04/23/09, 11:57:20 AM
I was just about to say, what if you subbed in the second SP...but you're right, that violates our league rules.
Just for educational purposes, wouldn't that situation look like:
FF 09 00 00
Yep... the only time that you couldn't determine the SP is if both starters pitched, and they were both subbed out - in that case, they're both hosed.
If you're into assembly hackage, the way to track that might be to set a counter for each team that decrements every time a player is subbed - instead of replacing their lineup position with 0xFF, you replace it with the counter (1st sub - 0xFF, 2nd sub - 0xFE, etc.).
That'd be a great beginner project once I learn 6502...
That's a good idea, and I'd take it one step further. Start a counter at 0xFF, and decrement it every time an out is recorded. Then not only would you know the substitution order, but you could also pinpoint when substitutions are made and determine how many innings each pitcher went.
Of course you'd have a problem if the game went over 41 innings ...
Here's the culprit:
$AEEE> A9 FF: LDA #$FF ;
$AEF0> 99 4006: STA $0640,Y ;
Found in page 5 of the disassembly. Now to find space to change that ...
Even better. Same page, incrementing the error counter ...
$AB9B> EE 1E01: INC $011E ;
I'm making an executive decision and defining 0x07F0 as our out counter, since I can't find it being used anywhere else. We're also fortunate in that page 4 has unused space at the end and is loaded at 0x8000 in both instances above. Make the following changes:
- Change incrementing the error counter to include decrementing our out counter:
page 4:
$9F9B> EE 1E01: INC $011E;
$9F9E> CE F007: DEC $07F0;
$9FA1> 4C 9EAB: JMP $AB9E;
page 5:
$AB9B> 4C 9B9F: JMP $9F9B;
- Change the byte written on a player substitution from #0xFF to the value at 0x07F0:
page 4:
$9FA4> A8: TAY;
$9FA5> AD F007: LDA $07F0;
$9FA8> 4C F0AE: JMP $AEF0;
page 5:
$AEED> 4C A49F: JMP $9FA4;
Next we need to find a way to initialize 0x07F0 with #0xFF ...
Fantastic. 0xFD66 is the location of the subroutine that plays the "start game" music. Good time to initialize data. It's called from:
$A8E8> 20 66FD: JSR $FD66 ;
Which is, once again, in page 5. And page 4 is still loaded at 0x8000. Booyah.
page 4:
$9FAB> A9 FF: LDA #$FF;
$9FAD> 8D F007: STA $07F0;
$9FB0> 20 66FD: JSR $FD66;
$9FB3> 4C EBA8: JMP $A8EB;
page 5:
$A8E8> 4C AB9F: JMP $9FAB;
Last thing to do is make sure the check for usable players won't puke at this ...
Problem.
$A482> A9 FE: LDA #$FE ;
$A484> A0 02: LDY #$02 ;
$A486> 91 36: STA ($36),Y ;
$A488> C8: INY ;
$A489> BD 4006: LDA $0640,X ;
$A48C> D0 06: BNE $A494 ;
The accumulator is loaded to #0xFE then directly compared to the team lineup data discussed above, checking for a not equal condition. That needs to be changed. I just wrote out a bunch of shit and now I don't think it's right. I'll come back to this after work tomorrow.
HAHA! Awesome...much more rubust than my "If x68D == xFF" { $starter = 'SP1' }
Apparently too much of this shit at once makes me stop thinking clearly. The lines above ...
$A489> BD 4006: LDA $0640,X ;
$A48C> D0 06: BNE $A494 ;
... load that pitcher's data from the lineup. If the current value is 0, that pitcher is available. If it's non-zero, the pitcher is not available. So, the changes made don't affect the game engine at all with regards to determining which pitchers are available.
Next up is actually patching all of this into a ROM to see if it works ...
Just finished (or almost finished my 2009 league rom). Perfect timing for you to come up with this, as I know the league will enjoy it...
If it's all ready, I'll be glad to throw it on my rom and give it a whirl...
Minor problems. The increment statement at 0xAB9B only runs when an out is recorded due to a strike out. Any out in the field is incremented from 0xD78E. Simple fix ... just have to add a routine there.
Other problem is that the game crashes any time the computer "randomly" picks a pitcher while the game is in play. Since this doesn't affect 2-player play it's a low priority to fix, but I don't like putting out anything that doesn't work properly.
Problem found. The game jumps to 0xAEEE after "random" pitcher selection, which is right in the middle of our patched code, causing the crash. Moving ...
Everything works, but when a pitcher is brought in via pinch-hitting in the ninth spot, the pitcher's "out count" is overwritten. Fixing ...
I think everything works. Did a bunch of reordering ...
- decrement counter on out, from strikeout
$9F93> EE 1E01: INC $011E;
$9F96> CE F007: DEC $07F0;
$9F99> 4C 9EAB: JMP $AB9E;
$AB9B> 4C 939F: JMP $9F93;
- decrement counter on out, from field
$9F9C> EE 1E01: INC $011E;
$9F9F> CE F007: DEC $07F0;
$9FA2> 4C 91D7: JMP $D791;
$D78E> 4C 9C9F: JMP $9F9C;
- replace lineup data with out decrementer (pitcher sub)
$9FA5> AD F007: LDA $07F0;
$9FA8> 99 4006: STA $0640,Y;
$9FAB> 4C F3AE: JMP $AEF3;
$AEF0> 4C A59F: JMP $9FA5;
- replace lineup data with out decrementer (pinch hitter in ninth spot)
$9FAE> AD F007: LDA $07F0;
$9FB1> 99 4006: STA $0640,Y;
$9FB4> 4C A3AE: JMP $AEA3;
$AEA0> 4C AE9F: JMP $9FAE;
- initialize counter on game start
$9FB7> A9 FF: LDA #$FF;
$9FB9> 8D F007: STA $07F0;
$9FBC> 20 66FD: JSR $FD66;
$9FBF> 4C EBA8: JMP $A8EB;
$A8E8> 4C B79F: JMP $9FB7;
This can be patched into any 96k ROM by anyone handy with a hex editor, at the following ROM (not RAM) offsets ...
0x9FA3> EE 1E 01 CE F0 07 4C 9E AB
0x9FAC> EE 1E 01 CE F0 07 4C 91 D7
0x9FB5> AD F0 07 99 40 06 4C F3 AE
0x9FBE> AD F0 07 99 40 06 4C A3 AE
0x9FC7> A9 FF 8D F0 07 20 66 FD 4C EB A8
0xA8F8> 4C B7 9F
0xABAB> 4C 93 9F
0xAEB0> 4C AE 9F
0xAF00> 4C A5 9F
0xD79E> 4C 9C 9F
A sample ROM is attached.
Perfect, I'll try it out tonight...I'll update the stat extractor too and post an alternate version...
Tried this out...
Inning 1, my lineup went:
SP2, SP1, RP, Closer. The save state file gave me this:
x678 - 01 02 03 04 05 06 07 08 00 00 00 00 FD FD FD 09
Is the expected? This tells me that the SP1, SP2, and RP were all subbed out, and the game ended with the closer...
I would have thought each spot would contain the value at which they were subbed, so in the aforementioned situation, the pitchers would contain:
... FE FF FD 09
Perhaps I'm misunderstanding...
Quote from: nightwulf on 04/23/09, 11:00:06 PM
That's a good idea, and I'd take it one step further. Start a counter at 0xFF, and decrement it every time an out is recorded. Then not only would you know the substitution order, but you could also pinpoint when substitutions are made and determine how many innings each pitcher went.
Of course you'd have a problem if the game went over 41 innings ...
I'm guessing you subbed them with the same number of outs.
I did...does the counter only decrement after an out? I didn't catch that part...
Quote...decrement it every time an out is recorded.
I just read that now. Jesus, my bad. I was thinking it'd decrement when the player is subbed, not when an out occurred...
Started working on the editor, got the meat of it done so players can be edited and the 2 player pause hack can be applied. I did everything in php reading data from a spreadsheet first so I had the locations and layout working, and when it's done I'll port it over to a c# application. Been fun so far, lots of work left to do.
Awesome, keep up informed of the updates and I'm sure you'll have plenty of beta testers on here if need be.
Will do. I think I'm gonna make it text bases like TSB Tool is for easy manipulation and moving between csv and excel and all that. Only thing I don't know if I can duplicate from wulfs editor is the auto generation of the two-letter team abbreviations. I still don't understand how that all works, as for graphics I usually just did that stuff by hand. It'd be nice not to have to. That'll just have to be something I try and figure out at the end.
Other than that I'll shoot for most of the features he provides.