@ Lua scripters

[Archez]

Which tables would you need to script a proper shop system communication script? I mean, Gesior AAC z_ots_communication is a God damn mess, and I want to do something clean and understandable, not just "param1", "param2", "param3", etc...

So you tell me, which tables would you need? (please)

 

[Zonet]

I guess you mean columns
Make with commands ingame?

 

[Jano]

^ because he is developing an AAC.

-id
-guid
-itemid
-count
-status
-container
-subcount

should be enough for Lua

 

[soul4soul]

and i dont see why it can be something like "webshop" instead of "z" thats just bad naming

 

[Archez]

^ because he is developing an AAC.

-id
-guid
-itemid
-count
-status
-container
-subcount

should be enough for Lua

How many fields do you need to know where to send the item and who sent the item. ( I mean, do you need account ids, player ids, player names, account names?)

and i dont see why it can be something like "webshop" instead of "z" thats just bad naming

It will be "__archez_shop_communication".

I guess you mean columns
Make with commands ingame?

Mmm, I am not doing the lua scripting part, so I am asking lua scripters to tell me which fields in the __archez_shop_communication table they will need.

 

[iruga]

player_id and player_names, account names no :s because already have player_id or name, unless you'll send the item to every players in a account.
"depot_cityname" will be perfect too

 

[Archez]

player_id and player_names, account names no :s because already have player_id or name, unless you'll send the item to every players in a account.
"depot_cityname" will be perfect too

This is what I have in mind, tell me what you think.

• id (transaction id)
• itemid (item id)
• containerid (in case type is container)
• amount (amount of items)
• status (delivered or not)
• type (item or container)
• fromaccount (using account ID)
• toplayer (using player ID)
• extra (extra will be the text field that could be used as fromplayer (name))

More about extra:
People will get to choose between sending the item/container to their own character or not, that's the time when the extra field will be used, to save the name of the player who sent the item/container.

There is another way too... using the highest player of the account and removing extra, but I think that there will be people that won't like that, so I think extra is better.

Considering the fact that you have functions to get player name with ID, that's why I use toplayer (id).

@ Jano:
What are guid and subcount going to be used for?

 

[Bogart]

what about VIP/unban/remove skull/etc

 

[Archez]

what about VIP/unban/remove skull/etc

VIP: mmm, most of the otservers out there, or all of them use items in-game for this feature, so that is considered as an item for the archezaac store.
Unban and remove skull: already solved, as there is a type field in __archez_store_items.

 

[zakius]

I'd say you need attributes also(in case you would like to sell edited items)
and then this system could be easy adapted to auction system also
(and IMO the containerid can be stored just in extra, if item is itself container just use itemid, if its container of itemid put containerid in extra field and luascript should just create this container and fill it with itemid imo, w/o need to set ammount of items, just in case you sell single stachable/with charges the extra can be used as subtype)

 

[Archez]

I'd say you need attributes also(in case you would like to sell edited items)
and then this system could be easy adapted to auction system also
(and IMO the containerid can be stored just in extra, if item is itself container just use itemid, if its container of itemid put containerid in extra field and luascript should just create this container and fill it with itemid imo, w/o need to set ammount of items, just in case you sell single stachable/with charges the extra can be used as subtype)

Now tell me what you think about this:

• id (transaction id)
• itemid (item id)
• containerid (in case type is container)
• amount (amount of items)
• subamount (for stackable items)
• attr (you would have to find your way to use this field)
• status (delivered or not)
• type (item or container)
• fromaccount (using account ID)
• toplayer (using player ID)
• extra (extra will be the text field that could be used as fromplayer (name))

@ about using extra for containerid:

How are you going to know who sent the item/container to the player?

 

[zakius]

I don't exactly know what you want to get here so...
if its only usage of extra why dont just call it "from" or sth? and then use another field "other" as I said earlier? I'd have to think bit more and analize it but I like minimized things ^^

 

[Derek Boom Boom]

I store realized transactions and pending transactions in separated tables for better performance, think of that too.

 

[Jano]

How many fields do you need to know where to send the item and who sent the item. ( I mean, do you need account ids, player ids, player names, account names?)

There is no need to handle fields like account ids, from_player, to_player in Lua, well from_player maybe to know who sent you the gift.

type (item or container) is useless, if there is container id means is container type

Also as said before handling transaction information is not neccesary in Lua, fields like from_account, to_account, points_used, etc (excluding delivery status) should be in another table with a link between id (transaction id) and a field there

 

[soul4soul]

VIP: mmm, most of the otservers out there, or all of them use items in-game for this feature, so that is considered as an item for the archezaac store.
Unban and remove skull: already solved, as there is a type field in __archez_store_items.

but what about premmy? i use premium as a "VIP" status because it just makes more sense.

 

[Jano]

^ item that adds premmy days?

 

[Archez]

There is no need to handle fields like account ids, from_player, to_player in Lua, well from_player maybe to know who sent you the gift.

type (item or container) is useless, if there is container id means is container type

Also as said before handling transaction information is not neccesary in Lua, fields like from_account, to_account, points_used, etc (excluding delivery status) should be in another table with a link between id (transaction id) and a field there

So, your final suggestion is...? :3

 

[soul4soul]

^ item that adds premmy days?

why not just let amount = the amount of premmy days if type is premium? not having to use an item can be better in some cases.

 

[Darkhaos]

shop_items

• id -(Autoincrement) transaction id.
• name -Product name.
• item -Item id.
• count -Item count.
• container -Container id, if = 0 then will be ignored.
• containerCount -Container slots that will be used, ignored if Container = 0.
• type -Product type ([1] = Item, [2] = Outfit, etc)
• price -Of course the product price.
• desc -Product description.

shop_history
(All player's transactions will be saved here, GOD can see all server's shop shitory while players only can see its shop history)

• id -(Not Autoincrement) transaction id.
• name -Product name.
• item -Item id.
• count -Item count.
• container -Container id, if = 0 then will be ignored.
• containerCount -Container slots that will be used, ignored if Container = 0.
• type -Product type ([1] = Item, [2] = Outfit, etc)
• price -Of course the product price.
• desc -Product description.
• buyer -Who bought the product.
• date -When it bought the product.

That's what i'm using on my Shop System via Talkaction

Explanation for types

Id (Autoincrement, used in all products) --[[
[1] = Player will buy an item (Item = Itemid, Count = item count)
[2] = Player will buy an outfit (Item = Outfit ID, Count = How many addons)
[3] = Player will buy a skull removal (Only name, price, and description will be used, other parameters are ignored.)
[4] = Player will change it name (Only name, price, and description will be used, other parameters are ignored.)
]]

 

[Archez]

@darkhaos:

I need to know which fields you scripters need in __archez_store_communication. Lua script to database connection, to check whether the product was delivered or not. :x