BT 1 CBM64 roster file format

[Quantum Reality]

You all may have noticed these bytes:

Code: Select all

3a - 3c      ????      ????
3d      byte      ???? seems to be set 

I'm going to attempt to investigate if these might contain status bits for various items used by the character and how many "tries left" there are.

As noted by the screenshot, the character has a Flame Horn. I'm going to go into a battle with it, use it once, then save the character and see what bytes have changed. The bytes that changed will (aside from that we know the XP and Gold will change), hopefully, tell me how item-use is stored.



Yep, it changed!



So, in conclusion, those bytes store information about items that have a finite use. I'm going to test this under some highly artificial conditions so BRB.

[Darendor]

You may be interested to know that I am highly insane.

[Quantum Reality]

So here's the results of a test I did. Copied a blank character disk to a new disk image file, made a character and saved him to a team. For simplicity I made him a human warrior when I rolled the stats.

So here's what he looks like under the magnifying glass of my sector editor:



I gave him a Flame Horn.



Sent him into battle with the first group of baddies near the Adventurer's Guild, then went back and used the disk options to save him off before rebooting into Copy ][ Plus.



Aside from the loss of hit points and the gain of XP and gold, the only other thing that changed was a $01 has been placed in a byte where a $00 was before.

Next step will be to give the guy TWO flame horns and see if the position in the equipment list affects things. It's obvious that a counter gets incremented and each item in Bard's Tale that has a finite-use amount gets compared against some internal table. Investigation proceeds!

[Quantum Reality]

Sigh.

He died. Well, I just didn't save him, and he lost all his gold but bleh. I cheated and gave him 128 hit points, so he should be a little more robust.

Anyway the conclusion seems to be that even if the position of the item is different in the equipment list the same item-use counter gets incremented. So I guess if you had more than one flame horn they'd both disappear at the same time once it rolls over to $FF.

Darendor pointed out that infinite-use items would need a status flag corresponding to $00 or $FF, and it looks like $00 is the infinite-use flag.

Pictures below as usual.





Looks like what I'll do for my character editor is just offer a "reset all items to brand-new" and clear those bytes to zero when that option is set.

[Quantum Reality]

Ok, not gonna throw you a whole bunch of screenshots since you all probably have the idea by now.

I reset the items used byte to zero, then changed the second Frost Horn to $66, a Ybarrashield. Loaded the character's team, went out, used the shield, went back, rebooted into Copy ][ Plus after Disk Options Leave Game, and no change to that byte.

Went back, used the Flame Horn, and sure as shooting, that same byte got incremented.

Am going to add a Frost Horn and see how it rolls.

EDIT: This is weird. I added the Frost Horn to the third slot and I saw no bytes get changed. I'm wondering if it's because I'm not setting some other status bit when I add the item to my character by direct editing, versus picking it up during a battle.

Well, wait - what if it's every TWO or THREE uses that trigger the increment? This would require that a byte somewhere else on the disk is being changed, but I have no idea where it would be. Might be time to learn how that debugger works, eh?

[Quantum Reality]

As noted elsewhere by ZeroZero, my initial supposition was wrong; the bytes involved actually count the number of fights the character has been involved with in some way, "(D)efending" doesn't seem to count.

I'll take a crack at the bottom bytes in the blank spot from ~$60-$7F later on.

[ZeroZero]

The counter will increase for each fight the party finished (= won) and for all chars alive at the end of the fight.

[Darendor]

The counter will increase for each fight the party finished (= won) and for all chars alive at the end of the fight.

So, if a party of 6 characters survives a battle, the counter increases by 7 then?

[Quantum Reality]

You know, I didn't check that out. The time I used just the frost horn (or flame horn?) the counter incremented by one for my guy. I didn't check the other characters though. I'll look into it tonight or tomorrow.

[ZeroZero]

The counter increases by one. It increases for every char alive after the fight.

[Darendor]

The counter increases by one. It increases for every char alive after the fight.

I don't get it.

[Darendor]

I decided to paste the entire text of that Computerist article for the Apple II character editor, just because.

I was a bit skeptical when I first purchased The Bard's Tale. Having been a Wizardry nut for yours, I was doubtful that anything could match it, much less better it! Well, I was wrong. The color graphics are superb and it plays much smoother and easier than Wizardry. However, don't construe that to mean that it's easy to beat! After my favorite wizard, Frobozz, was fried to a crisp by a wandering dragon, I decided there had to be a better way. There was and here it is.


Background

All of the characters that you create are stored on track $00 of the character disk you made according to the game instructions. They are stored two per sector for every sector except $0. That means you can maintain up to 30 characters and/or parties on each disk. The remainder of the disk is game data and the map of Skara Brae.
In each character sector, bytes $00 and $80 begin the name of a character or party and all character or party data follow that for precisely 1/2 sector. As the article progresses I'll try to explain where each item is and what it means. Although I believe I've located the important characteristics, there are still assorted bytes that I haven't been able to figure out. For the more curious, discovering what the other bytes are could be an interesting project.
When The Bard's Tale saves a character to disk, it computes a checksum and writes it to the last byte of the character. On reloading, that checksum is verified against the character data and if it isn't correct, the game tells you that character doesn't exist. Fortunately, the checksum isn't verified if the character is loaded via a party load. If the name of your modified character is on a party roster, just load the party and resave your character with the R(emove) command. A new checksum will be computed and your problem will be solved. If he isn't on a party roster, this editor can put him on one. Characters cannot be created or deleted with THE DRESSING ROOM. You must edit a character that has already been created in the game. The same applies to party rosters.


Making It Go

Just type in the Applesoft listing and SAVE it as "THE DRESSING ROOM" (I realize it's long, but keep the faith). As soon as you RUN it you will get a reminder on loading modified characters into the game and will be advised to place your character disk in the drive of your choice. Just press the number of the drive your disk is in and it will then read the names from the disk and present you with a Master Roster of all your characters. The names will be listed in pairs (two per sector, remember?) and you will be able to edit both, if you wish, before writing them back to the disk. Once a character is selected for edit, each menu displayed will have all command keys listed at the bottom. There is no need for written documention to operate The Dressing Room.

While debugging The Dressing Room, it would be a good idea to make line 280 into a REM line until finished because that is the line that writes your characters back to the disk. Each time you return to the main character display, the data is read from the buffer just like it will be written to the disk. So when that looks right, it probably is.

One final note. Since the Dressing Room usees the RWTS directly, it will only work on a DOS that has a standard DOS 3.3 RWTS and uses DOS 3.3 page $03 vectors. If in doubt, boot with your DOS 3.3 System Master. If your character disk is write protected when you try to write your character back it will pretend to write, but it really won't. If you're not sure, read your character back into the buffer and check it.

[bytesmythe]

QR,
Not sure if you'll ever see this, but I don't think item uses get saved to disk (at least not in the MS-DOS version). I experimented a little by having a bard buy a new fire horn and use it until it expired. The first one only lasted 4 blasts before disappearing!

I think what happens is when the item is loaded into the game, it is given a random number of available uses. The range goes low enough that, at some point, you'll essentially be guaranteed to use them up before going back to the AG, removing the character with the item, and reloading it.

The way to test this would be to:
1) have a bard buy a new horn
2) use it once
3) remove character at AG
4) reload character
5) repeat steps 2-4 a large number of times (larger than the longest you've ever had the horn last)

I originally thought items would have a saved state, so I had been looking for a change to a file somewhere. I actually tried this:
1) created a new bard
2) gave him a horn and removed him
3) backed up his character file w/ only the horn in inventory
4) loaded him back up
5) loaded another bard
6) gave horn to bard 2
7) removed bard 1
8) had bard 2 go out, use the horn once
9) reload bard 1
10) give horn back and resave bard 1
11) compare current save against the backup from step 3. They were identical.
12) Just for kicks, I compared the entire directory. All the files were the same.

So, I don't think there is ANY saved state indicating the uses remaining for items.

[ZeroZero]

In fact in the 8-bit versions of BT1, the item use time is never at
any time be set by the game. Items have a 1/64th chance of expiring
on EVERY SINGLE use.

An item can expire after one use or last forever that way.

When an item expires (test is before use), that item works for that
very last use, then vanishes.

[bytesmythe]

Ah! Thank you for the explanation. I had searched for that kind of info, but didn't find anything but this thread.

I'm assuming if every item has the same chance of expiring that the same code is handling it? If that's the case, do you happen to know if there is a description somewhere of how to modify that code in the MS-DOS executable?