Remove this ad

Lead

Jun 8 09 11:35 PM

Tags : :

I am still around here >.>

Anyways, I started fooling around with items, never really did get into it when the FreeHand Item program was made. So, I thought I would bring it back up again. Using copy and paste:
Public Type ItemHeader
AClass As Byte
BSubclass As Byte
CCost As Long
DUnknownA As Integer
EItemActivation As Byte
FStatus As Byte
GStatusB As Integer
End Type

Public Type EffectSlot
AEffect As Byte
BEffectActivation As Byte
CChargesHours As Integer
DPowerLevel As Integer
ESummonMons As Long
End Type

I think I know what "DUnknownA" is. When it is 0, the item is its ingame name, but when the integer is anything but 0 (as my tests seem to have proved), the data (below) proceeds after all listings of type EffectSlot
Public Type ItemName
ALength As Byte
BName As String 'Only as long as ALength is
End Type


Furthermore, there seems to be a set order with equipped items. Do you think it's possible to add an item to your Free Hand while wearing equipped items?

Edit: Wow... just moving my bracers to the free hand changed a massive amount of information in the save file. Anyways, what's the setup for a belt? Same thing as a regular item just with some extra bytes?
Quote    Reply   
Remove this ad
Remove this ad

#2 [url]

Jun 22 09 4:22 PM

Alright for the file saving it seems the structs are directly written. C likes to do stuff like pad out structs to 4 byte boundries and other things which can be configured and may vary from compiler to compiler so there may be extra empty space than I list here after the structures in the save files. Similarly bit fields were used for various variables and ordering and padding are really up to the compiler. So best to open up a save in a hex editor and see if what I give matches up before making assumptions.

Anyway! On to the good stuff the object struct.


objectType - 1 byte
subType - 1 byte
value - 4 bytes
name - 2 bytes (pointer to the string contents)
bitfield (all members are unsigned) - 4 bytes total
{
wieldActions - 1 bit
unwieldActions - 1 bit
activateActions - 1 bit
useActions - 1 bit
deleteOnActivate - 1 bit (for consumables like potions and scrolls)
charged - 1 bit (does it have limited charges)
identify - 2 bits(how is it identified on use, wield, etc)
identitied - 1 bit
enchantment - 2 bits(normal, enchanted, cursed, uncursed)
multiple - 1 bit(is it a stack of the same item?)
objlistflags - 3 bits
objlist - 1 bit (is it an object list ie: containers)
attributes - 4 bits (number of special attributes)
attributesAllocated - 4 bits(number of special attributes allocated)
descriptionType - 3 bits
unused - 5 bits
}



After that it writes out the object attributes struct for however many it has as defined in the object struct. After that if the name handle was valid it writes the name prefixed by a byte with the length of the name. The object attributes structure is as follows.


bitfield (all unsigned) - 4 bytes total
{
attrib - 10 bits (comment in the code just sets what happens so I imagine it's enumerated elsewhere)
wield - 1 bit (attribute kicks in when wielded)
unwield - 1 bit
activate - 1 bit
use - 1 bit
timeActivate - 1 bit
fuse - 1 bit (A delayed action)
identified - 2 bits
count - 14 bits (The fuse delay)
}

wParam - 2 bytes
lParam - 4 bytes


Not sure what wParam and lParam are used for since it's not commented at this part in the code. So many random extra information or something depending on what it is.

And for containers there seems to be the OBJLIST struct which is set up as follows


objectType - 1 byte
subType - 1 byte (should always be a contianer)
value - 4 bytes
nameHandle - 2 bytes
bitfield(all unsigned) - 2 bytes total
{
used1 - 3 bits
useActions - 1 bit
used1A - 2 bits
identify - 2 bits
identified - 1 bit
enchantment - 2 bits
used2 - 1 bit
fixedWeight - 1 bit
fixedBulk - 1 bit
noExpand - 1 bit
objlist - 1 bit (should always be true for an object list)
}

handleToParentObjectList - 2 bytes
weightMax - 4 bytes
bulkMax - 4 bytes
weightFixed - 4 bytes
bulkFixed - 4 bytes
slots - 2 bytes (number of used slots)
slotsAllocated - 2 bytes (number of slots allocated)

This is then followed by the slot structures for as many slots that are used. Then possibly followed by a name like with the object. After the name the actual object information is written and if the object happens to be a container it is recursively written using this same method and structure.


The first part of the object list structure(up to the end of the bitfield) is meant to match the object structure. So those used entries in the bit field for the object list are just meant to be filler so everything matches up.

And here's the slot structure

bitfield(all unsigned) - 1 byte total
{
objectType - 7 bits
mustBeExpandable - 1 bit
}
subType - 1 byte
objectHandle - 2 bytes

Quote    Reply   

#3 [url]

Jun 29 09 12:23 AM

Very nice! When I get time, I'll begin comparing the coded structures to the known structures. Looks like I shall have some fun with this newest information.

Anyways, wParam and lParam are used in Windows API programming and can you find the information regarding the data just before the Start of Player Equipment data?

I was out camping with my family last week, so that's why I'm replying now.

Quote    Reply   

#4 [url]

Jun 29 09 2:04 PM

Nova wrote:
Anyways, wParam and lParam are used in Windows API programming and can you find the information regarding the data just before the Start of Player Equipment data?


Well the basic layout of a savefile at a quick glance is

Header struct
player struct
player name
array of player attribute structs
attack struct
array of player special attack structs
array of spell structs
array of shorts which index the spell structs for which spells are on the player menu
icon filename
player inventory
a set of bits indicating which wands are identified
a set of bits indicating which scrolls are identified
a set of bits indicating which staffs are identified
a set of bits indicating which potions are identified
fuse struct for the current fuse
fuse list struct
256 bytes for future use
array of store structs
for each store
{
if it has a name write it
if it has an object list write it
}
a bunch of info on the state of the windows
inventfile struct
and the rest looks like stuff for the scene information(maps) and the daemons .

Like I said I just ran through the save file and didn't look around at all the structs and functions referenced. Which section of that are you after info on?

Quote    Reply   

#5 [url]

Jun 29 09 7:22 PM

Like I said I just ran through the save file and didn't look around at all the structs and functions referenced. Which section of that are you after info on?

Just before the player's equipped items are written into the file, there seems to be a number of various 2 or 4 byte numbers that seem to constantly change when you change the location of a equipped item, such as moving a equipped bracer to your free hand and vice-versa.

If we can locate the right information, we can begin to add items into the player's inventory/equipped items list without having to drop everything onto the ground.

Quote    Reply   
avatar

Gil

Manticore

Posts: 317

#6 [url]

Jul 3 09 1:15 PM

Much love Theodis

Do you ever talk on MSN? I tried contacting you a few times, but you don't seem to reply.

Quote    Reply   
Remove this ad

#7 [url]

Jul 5 09 2:15 PM

Gil wrote:
Much love Theodis

Do you ever talk on MSN? I tried contacting you a few times, but you don't seem to reply.


I do talk on MSN. You just managed to message me while I wasn't around and by the time I got back you were already off yourself. But anyway I am typically busy during the summer months and will be very busy for the next 6 weeks. But by the time september comes around I'll almost always be around my computer and have endless free time again.

I generally do have the weekends off though so for the next 6 weeks that's probably the best time to get into contact with me that or later in the evening my time(Pacific Standard).

Quote    Reply   

#8 [url]

Jan 9 10 1:24 AM

Very useful info, at least for the Freehand editor(Now at 1.3.

http://www.freewebs.com/castleofthewinds/

I've updated what I could do in a day, and may even play with pack(as opposed to belt) editing if time permits.

The changes should be pretty obvious with a little look through the program, but to be sure, it now lets you choose what items have been identified, and also allows you to pick specific characteristics for item activation.

Check under Dynamic Stats, and the main item editor for visible changes.

For source scroungers, I've connected as much of the source as I could to the bits and pieces of the program that are relevant. Mainly, check the item type structures, and you'll find a few mainly visual updates and comments based on what was posted above. The info is much appreciated, and gave me more ideas than I was expecting.

Quote    Reply   

#9 [url]

Oct 19 11 12:24 PM

So, after not really doing anything with CotW for a remarkably long time, I re-picked up this particular project.

I have created a very basic player inventory viewer. I currently have no support for for any items that may be in packs, belts or purses but I thought I'd share my progress.

(OffTopic: My last post here was in 2009. Although I've been checking the forum every day)

Quote    Reply   
avatar

Theta

Manticore

Posts: 299

#10 [url]

Oct 30 11 8:59 AM

Nova wrote:
So, after not really doing anything with CotW for a remarkably long time, I re-picked up this particular project.

I have created a very basic player inventory viewer. I currently have no support for for any items that may be in packs, belts or purses but I thought I'd share my progress.

(OffTopic: My last post here was in 2009. Although I've been checking the forum every day)


Good to hear.

Quote    Reply   

#11 [url]

Jun 6 12 12:36 AM

Hi everyone. Once again, I've picked up this project and have made some progress.

There is indeed a precise order in which equipped items are written into the save file. So far, I have seen the order to be thus:

Armor, Bracers, Weapon, Left Ring, Belt, Shield, Gauntlets, Free Hand, Right Ring, Boots, Necklace, Cloak, Helmet, Backpack, Purse.

Furthermore, starting at offset 0x41A, are five byte segments indicating if an particular item is equipped in that slot and is the same order as above.

I have managed thus far to create a moderately working viewer to view the player's equipped inventory and haven't progressed too deep into backpacks and belts.
Although I currently only have support for armor and none for any items such as potions, scrolls, wands, etc.

My current plans are to add support for potions, scrolls, etc and be able to read equipped belts, and then show what "enchants" are on the armor/weapon.

Here is a picture of my current progress. It's not very pretty, but it works.

[URL=http://imageshack.us/photo/my-images/85/cotwviewer.jpg/]image[/URL]

Uploaded with [URL=http://imageshack.us]ImageShack.us[/URL]

Quote    Reply   
avatar

Theta

Manticore

Posts: 299

#12 [url]

Jun 22 12 9:31 AM

Good to hear Nova!

Quote    Reply   
Remove this ad
Add Reply

Quick Reply

bbcode help