Jump to content

How to determine hex locations? (flat file database structure)


Recommended Posts


36 minutes ago, jumper said:

+1 to each of your last posts for continuing this interesting analysis. Thanks!

Yep :), but what is next?

I mean. it seems like the "Address" is a "plain" enough database, with 50 or so records (possibly 52), one for each team,

Then both the "Batters" and "Pitchers" are as well plain enough databases with respectively 739 and 477  records, corresponding *roughly* to 50*15=750 and 50*10=500, with the names and the characteristics of each player.

If they were my files I would probably put together an Excel spreadsheet and write a couple (half-@§§ed as always)  batches to "translate" forth and back the contents.

jaclaz

Link to comment
Share on other sites

My next step is to write a program that can read and write to these files. I still have to determine how to actually accomplish it. The main issue at hand is that I do not know what the "data" is in the player records. I know what it is, it is the stat data. Data linked to how well they hit, strikeout, walk or base stealing. I believe it to be quite simple, that it uses numbers to determine probability. BUT these numbers are weird and not actually baseball related. You can see them in the game itself if you look at an individual player's stats. So the options would be:

1. Go the next step and figure that part out to. Then I can do all roster management outside of the DOS program, including "deleting" and adding players.

2. Refactor the batters and pitchers files, to basically remove the players who are "deleted" from the file entirely, shifting their position in file number upwards, and adjust the address file accordingly.

3. Use a second instance to create players, get the data from the respective file and replace "deleted" entries with that data.

I think that the second choice would be the easiest... basically would be running a cleaner script on the files to remove unneeded data. The first option is more ambitious, but could include the function of the second as well.

Link to comment
Share on other sites

The memory model for the 16-bit app is either:

  Small: 64KB for all code and data in one segment,
  Medium: 64KB for code + 64KB for all data (two segments),
  Large: 64KB for code + multiple 64KB data segments.

If it used the Large model, each file could be loaded into its own 64KB segment and that would also be the file size limit. I suspect it is using one of the other models with ~14KB of common data or data + code, thus limiting each database to ~50KB. If you write a tool to modify the files, the limit will still be the same.

Link to comment
Share on other sites

Good.

if needed I can extend the Pitchers and Batters parsers to parse the "rest" of the data,

So, for pitchers (let's take the Jeff Ballard example) this is not correct:

Quote

Next 13 (size D) are stat based data
12 00 08 00 57 01 3D 00 40 00 08 01 66

Since in other fields were used "words" the data should be:

Next 14 are stat based data:

12 00 08 00 57 01 3D 00 40 00 08 01 66 00

And these likely translate to 7 fields:

PStatField #1 0x0012 -> 18

PStatField #2 0x0008 -> 8

PStatField #3 0x0157 -> 343

PStatField #4 0x003D -> 61

PStatField #5 0x0040 -> 64

PStatField #6 0x0108 -> 264

PStatField #7 0x0066 -> 102

Which BTW creates a nice, symmetrical situation with the batters (that is as well not correct, probably a typo):

Quote


Next 14 is stats based data
04 00 10 00 CF 00 80 00 B5 00 DA 00 24 00 49 00 D3 00 F8 02

As there are 20 Bytes, so for Brady Anderson that would be:

Next 20 is stats based data
04 00 10 00 CF 00 80 00 B5 00 DA 00 24 00 49 00 D3 00 F8 02

BStatField #1 0x0004 -> 4

BStatField #2 0x0010 -> 16

BStatField #3 0x00CF -> 207

BStatField #4 0x0080 -> 128

BStatField #5 0x00B5 -> 181

BStatField #6 0x00DA -> 218

BStatField #7 0x0024 -> 36

BStatField #8 0x0049-> 73

BStatField #9 0x00D3 -> 211

BStatField #10 0x02F8 -> 760

If you find these values in the visualization of the game statistics we can assign the right field name to each :).

jaclaz

 

Link to comment
Share on other sites

Pitchers: For the Jeff Ballard example, these reflect to these in-game values

PStatField #1 0x0012 -> 18 Wins

PStatField #2 0x0008 -> 8 Losses

PStatField #3 0x0157 -> 343 ERA (3.43)

PStatField #4 0x003D -> 61 Endurance

PStatField #5 0x0040 -> 64 Walks (1989 value: 57-5)

PStatField #6 0x0108 -> 264 Hits (1989 value: 240)

PStatField #7 0x0066 -> 102 Strikeouts (1989 value: 62)

Endurance, Walks, Hits and Strikeouts are under "Player Ratings", and the first three are under "Actual Stats". Actual Stats are not really used for anything functional in the game that I am aware of. They only appear on the Pitcher select screen and are used as a reference.

The data under "Player Ratings" are generated by the game when actual stats are input. Endurance has never seemed to make any difference if the number was high or low. Jeff Ballard's source stats for these values are Strikeouts (62) Walks (57-5) and Hits (240). I put the - on the walks because the game does have an input field for IBB, which I imagine that the game would not count as actual walks if it is using the walk rating for actual performance since IBB is a managerial decision. His IP from 1989 is 215.1 in 35 games.

I have determined that the Endurance value is IP / G (innings pitched / games) removing decimal.
For Jeff Ballard, Endurance = 61, IP = 215.1, G = 35 (215.1 / 35 = 6.1)
For Pete Harnisch, Endurance = 57, IP = 103.1, G = 18 (103.1 / 18 = 5.7)
For Gregg Olson, Endurance = 13, IP = 85, G = 64 (85 / 64 = 1.3)

For the other three values, I am presuming it would (normally) use the "total batters faced" input value,
For Jeff Ballard, his BF from 1989 is 912

Batters: For the Brady Anderson example, these reflect to these in-game values

BStatField #1 0x0004 -> 4 Home Runs

BStatField #2 0x0010 -> 16 RBI's

BStatField #3 0x00CF -> 207 Bat. Avg

BStatField #4 0x0080 -> 128 Walks (1989 values: BB 43, IBB 6)

BStatField #5 0x00B5 -> 181 Hits (1989 value: 55)

BStatField #6 0x00DA -> 218 2B per hit (1989 value: 12)

BStatField #7 0x0024 -> 36 3B per hit (1989 value: 2)

BStatField #8 0x0049-> 73 HR per hit (1989 value: 4)

BStatField #9 0x00D3 -> 211 Strikeout (1989 value: 45)

BStatField #10 0x02F8 -> 760 Speed (1989 values: SB 16, CS 4)

As with the pitchers example, the first three bits of info (HR, RBI, Avg) are informational. They appear in game as reference data when the batter is at the plate.

1989 AB: 266. Actual PA is 317 but the game doesn't ask for PA only AB. PA = AB + BB + HBP + SF + SH (of which, all besides HBP are prompted for, and you can put -1 in for SF and SH). So presumably, in-game PA would be 314 OR 320 if IBB are counted.

BstatFields 6-8 are percentages. 55 hits, of those 37 are singles (67.3%), 12 are 2B (21.8%), 2 are 3B (3.6%) 4 are HR (7.3%). Verified using this site: https://www.rapidtables.com/tools/pie-chart.html
Data names: 1B 2B 3B HR
Data values: 37 12 2 4

Also for real-world data the game uses, 1989 stats of any players in these examples, they can be found on Baseball-Reference, ie: https://www.baseball-reference.com/players/a/anderbr01.shtml

Link to comment
Share on other sites

Very good :)(though obviously I only understand half of the baseball terminology :blushing:).

But the point is (now that we have defined and know exactly what those data are) do we (actually you) *need* to edit them?

Or they can be treated like if they were - say - a block of data representing the date of birth of the player (which you won't change/touch at all )?

Now that we know how the contents is arranged in records, Managing them with a spreadsheet and a couple command line tools should be straightforward (maybe slow, but simple enough)

Jaclaz

 

Link to comment
Share on other sites

I put together the usual half-@§§ed set of batches+spreadsheet, find the whole stuff attached, create a new folder, and uncompress the contents of the archive to it (to work with new data you will need to copy the pitlist.mps and batlist.mps to the TinyHexer scripts\Structure Viewer folder)

In folder "NewFiles" there are:

Batters2019
Pitchers2019
Address2019

files which I re-generated to see if the procedures work.

Basically I took "Address2016" and regenerated, re-ordering them according to their position in Address2016 the Batters2019 and Pitchers2019, then re-created a new Address2019 file re-indexing the new Batters2019 and Pitchers2019.

In practice the result should be the same teams as in the 2016 files, but "more ordered", let's call the new files "defragmented" :w00t:.

At first sight the files seem correct (though due to the way the cmd generated by the spreadsheet there are still some "holes") but the only way to know is to try the files in the program.

I split the Batters and Pitchers (both the "old" and the "2016" versions) in single entries (single files, stripped of the "prefix" or Team#) and the spreadsheet "MkNewFiles" creates a batch (in column N, copy and paste to MkNewFiles.cmd) that reassembles them and creates in column J the new address file (copy and Paste to New in TinyHexer selecting "Hex text").

jaclaz

 

Trip_Baseball.7z

Link to comment
Share on other sites

  • 3 months later...

I finally got back to this project. There is something wrong with the 2019 files in the zip attached earlier. I first noticed when looking at Team 47

Team 47 using 2019 files:
GdG3gBJ.jpg

Team 46 using 2019 files:
ssPVIF8.jpg

Team 46 using 2016 files:
CIRHPeM.jpg

The expected result is that the rosters for each team should remain the same between the 2016 files (generated by the game) and the 2019 files (generated by the scripts).

Link to comment
Share on other sites

At first sight the Excel file looks good, what you have as "team 46 using 2019 files" should be team 39.

Try checking the teams one by one against the Excel, most probably there is a "slip" somewhere".

But the Batters2019 file is also fine, Chone Figgins, etc. are on team 46. :unsure:

jaclaz

 

Link to comment
Share on other sites

  • 2 weeks later...

I found it. The "placeholder" data that you created into the spreadsheet (mknewfiles tab) are written oddly into the game.

Starting with team 28, it matches to the spreadsheet, there there are 5 pitchers and 15 batters:

QAQnXr0l.jpg

The five pitchers marked "tomorrow" and the batter marked "naturally on first" from team 28 are written into the slots for team 29. This is how they appear in the game (team 29 roster)

ipWGPfxl.jpg

So then team 30 has the 5 pitchers from team 29, and 4 of the forwardslash entries, for batters it has one batter from Team 29, a blank and then the first 6 batters (of 8) that are supposed to be on team 30.

Team 31 has one forward slash pitcher and the first 2 pitchers of team 30, the last 2 batters of team 30 and 6 blank entries.

Link to comment
Share on other sites

Ok, I see where the issue arises from.

I needed the Tomorrow and Naturally is on first as placeholders (to get the numbering right in the ADDRESS file) but they shouldn't be written to the actual Pitchers and Batters files, that are seemingly written sequentially without "gaps".

So it is just a matter of putting an IF condition in the N column of the spreadsheet and regenerate the files, though now fsz it is also needed to add the 00 bytes at the end of the Batters and Pitchers file to match the original "total size".

Try the new attachment.

jaclaz

Trip_Baseball_2.7z

Link to comment
Share on other sites

  • 2 weeks later...

Good.

Due to the way the files are made by the program, new additions (players) will be added at the end of the batters and pitchers files, thus the index/address file will become again not-sequential (even if only in the last part), and you will need - before or later - to re-run the scripts to re-compact it.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...