Item properties

[satori]

Yup, more from me. This time it's a list of item properties. I'm pretty sure it covers everything in the first book, not so sure about items later in the series that may have special effects (not like firesphere, but items that have weird properties)



Good/Bad?

[outspaced]

You might also want:

Item Type: 10 = Belt Pouch (you can lose/find these in earlier books); 11 = money

CS Boost: I'm assuming this only lasts for the duration of just one numbered section?

About money: How are you planning to deal with the different currencies (Gold Crown, Ren, Kika, Ain, Noble, Lune)?

Sorry if it sounds as though I just keep finding work for you!

[HuntingWolf]

My brain isn't functioning right.... I don't understand this thing thou hast made.....

[Zipp]

xhuntingwolfx said:

My brain isn't functioning right.... I don't understand this thing thou hast made.....

Basically he's made a list of all the things a program would have to know about an item. It's type, wehether it could be used as a meal, how it's carried, is it used in combat and how... things our brain does seemingly automatically that we take for granted until we look at code.

[satori]

outspaced said:

You might also want:

Item Type: 10 = Belt Pouch (you can lose/find these in earlier books); 11 = money

CS Boost: I'm assuming this only lasts for the duration of just one numbered section?

About money: How are you planning to deal with the different currencies (Gold Crown, Ren, Kika, Ain, Noble, Lune)?

Sorry if it sounds as though I just keep finding work for you!

Added beltpouch item, also added arrow (doh!). Edit: Added Crowns as a type, you were right

Yes, the CS boost is combat only, using sessions in PHP should handle all combat specific goings on.

Money will be stored under the player statistics (along with stats, items, arrows, etc...) and that will make coding shops much easier as well.

I updated the first post to reflect current table setup. Working on forms now. Once I have all the forms coded for all the tables, I'll u/l the db file, as that's really the best way to go through all the data.

The player stats page is WAY to long to get a screen cap on right now. After I get it fully built I'm going to try and combine some data in a WL inspired way. As far as I know, PHP does not support direct byte/bit data access, but this could be faked using ints, by using a function to strip powers of 10 right to left and run true/false checks on the result, as long as the integers used always had a '1001101001' numbering pattern. This should let me condense things like Kai rank, Weaponskill profs, and Lore Circles into single integer fields.

This should shrink things greatly, as well as doing the same for the pages table, where there are often dis checks and the effective 'pop' routine should be quick easy to do.

Jacob

P.S. Sorry for the screen warps on the posts, but if I shrink the screen caps the text gets unreadable.

[satori]

Ok, this is the current form for item entry, let me know if I'm missing anything. Cost in shops will be stored in the page table, not in the item table:



I'll show a cap after some items have been put in.

[satori]

Here it is, every item and it's conditionals. I left out fields that were not used (like damage multipliers and such)

Below pic is a legend. The first post includes details for non-included fields (Things no item in the first book had)



Item Type:
1 = Weapon
5 = Layer 3 Armor
6 = Backpack Item
7 = Special Item
8 = Extra SI (like special Item, but takes up no space),
9 = Backpack
10 = Beltpouch
12 = Crowns

Weapon Type:
This is used with Weaponskills. All 9 weapon types in the first book are listed cleanly in the table above. 11 is 'Not a Weapon'

2 Handed:
Um... If a weapon is 2 handed

SI Slot:
For my modified SI system, only 2 items in the first book.

Equipable:
If an item needs to be equipped to get benefits. Weapons are auto tagged, so the 'FALSE' for weapon records will never be checked. Only non-weapon items use this field.

EN Bonus:
The bonus you get to EN when this item is equipped (or is a weapon).

Consumable:
If the item can be used up (such as eating a meal, or drinking a potion).

CS Boost:
The bonus you get to CS when this item is used.

EN Restore:
The amount of EN restored when this item is used.

Meal:
If the item fufills the reqs. of a meal.

CS Potion:
If the item can be used directly before a combat.

Discription:
What the item is, currently not very good

PLEASE let me know if I categorized anything incorrectly.

Jacob

P.S. Yes, I spelled 'Helmat' wrong in the pic, no easy way to edit it like my normal bad spelling

[Zipp]

There may be one thing you've forgotten. Some items can be used more than once. Certain potions, for instance. Can your current system handle that?

[satori]

The beauty of the way I'm designing things is that functionality can be added, without much change. Currently the items don't have a (USES) field, when the first book that contains such an item is up on the chopping block, that field can be added to all the items. Since no items before that point had that attribute, a default of 1 can be assigned for all related existing items, and new items can be created with 1, 2, how ever many uses.

Then the code for expendables can be changed from: (this is abstacted code lacking some table/array calling, it also forces a limit of 1 CS item to be active, due to the '0 +' assignment, but it's just example code

Funtion Use(Itemslot)
If $ENrestore > 0
{
$currentEN = $currentEN + $ENrestore;
$currentEN = $currentEN > $maxEN ? $maxEN : $currentEN;
}
If $CSboost > 0
$tempCS = 0 + $CSboost;
Itemslot = NULL;
End Function

To:

Funtion Use(Itemslot)
If $ENrestore > 0
{
$currentEN = $currentEN + $ENrestore;
$currentEN = $currentEN > $maxEN ? $maxEN : $currentEN;
}
If $CSboost > 0
$tempCS = 0 + $CSboost;
Itemslot[uses] = Itemslot[uses] - 1;
If Itemslot[uses] <= 0
Itemslot = NULL;
End Function

Since all previous items get a defualt 1 assigned to thier USES field, they all work exactly the same under the new code. I am trying to design things from the ground up in this manner, so code and data can be updated on a book by book basis, while still maintaining compatability with all exisiting data.

This also makes it easier for other people to add code, so if at some point I am no longer able for whatever reason to code the next book, other people can step in and make changes according to the design plan and not be scared they will 'break' earlier book compatability.