PHP RBI Stat extractor (and an editor question)

[Turd]

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!

[TβG]

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??

[Turd]

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.

[TβG]

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.

[Turd]

RBIM I think edits in real-life stats...meaning 74MPH fastball vs. a numeric indicator from 0-255...

[TβG]

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?

[Turd]

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?

[TβG]

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.   

[BeefMaster]

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.

[Turd]

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...

[nightwulf]

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.

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.

[nightwulf]

This will help if you decide to tackle 6502 or dig up the guy who does.

[nightwulf]

Last one. This should give you something to work with on the editor-specific hacks ...

[Turd]

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.

[Darky]

You are well hung Nightwulf. I'm man crushing on you...

[Turd]

You are well hung Nightwulf. I'm man crushing on you...

Right on, why not? 

[BeefMaster]

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).

[broiler]

EARLY THROW BOP

[Darky]

You still have no evidence broiler...that only exists in your head.

[nightwulf]

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.

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 ...