SphereServer BugTracker - SphereServer
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002215SphereServerscript packpublic03-10-13 05:1216-10-13 01:51
ReporterCoruja 
Assigned ToRanXerox 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version0.56c Nightly 
Nightly VersionAutomated (specify build number)
Experimental FlagsNone
Option FlagsNone
Internal Build Number
Summary0002215: Dragon Scale itemdef properties
DescriptionSince i_ore_[...] uses typedef t_ore, i_ingot_[...] uses t_ingot, i_log uses t_log, etc
I think it's better follow it on Dragon Scale too and use t_dragon_scale instead t_normal. Also, some properties needs to be fixed too :D


on /items/sphere_item_resources.scp:

[ITEMDEF 026b1]
DEFNAME=i_dragonscale //weird name, maybe change it to i_dragon_scale?
NAME=dragon scale%s
TYPE=t_normal //change to: t_dragon_scale
VALUE=17 //on OSI this item is not bought/sold on any vendor, maybe this line could be removed, whatever
WEIGHT=0.7 //OSI correct weight: 0.1

CATEGORY=Resources
SUBSECTION=Animal
DESCRIPTION=Dragon Scales
Steps To Reproduce
Additional Informationt_dragon_scale must be defined on [TYPEDEFS] section of sphere_defs.scp too, because the itemdef will fall back to t_normal if t_dragon_scale is undefined
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-10-13 05:12CorujaNew Issue
04-10-13 18:45RanXeroxNote Added: 0001704
04-10-13 18:45RanXeroxAssigned To => RanXerox
04-10-13 18:45RanXeroxStatusnew => assigned
05-10-13 18:11CorujaNote Added: 0001712
16-10-13 01:51RanXeroxNote Added: 0001729
16-10-13 01:51RanXeroxStatusassigned => closed
16-10-13 01:51RanXeroxResolutionopen => fixed
16-10-13 01:51RanXeroxFixed in Version => 0.56c Nightly

Notes
(0001704)
RanXerox   
04-10-13 18:45   
The reason there is a t_ore is because ore can be smelted into ingots. The reason there is a t_log is because a log can be cut into boards. How do you think a t_dragon_scale should behave?
(0001712)
Coruja   
05-10-13 18:11   
actually theres no use yet, the typedef is just to make it consistent with these others resources for ppl using custom craft/resources engines

like this:
IF (<ARGO.TYPE>==t_log)
 ...
ELIF (<ARGO.TYPE>==t_ore) || (<ARGO.TYPE>==t_ingot)
 ...
ELIF (<ARGO.TYPE>==t_potion)
 ...
ELIF (<ARGO.TYPE>==t_leather)
 ...
ELIF (<ARGO.BASEID>==i_dragonscale) //lol
 ...
ENDIF

it's a worse example (create the whole typedef just to use it a single code line, which can be done without it), but the point is not that, ppl could use it better if they want, like use custom actions on the typedef, etc. The big deal of this is not really add a functionality to the typedef, but make it standard with the others materials (log, ore, ingot, etc)
(0001729)
RanXerox   
16-10-13 01:51   
Of the suggestions here, I only changed the weight. Our reasoning on the other things went this:

- Adding (or removing) characters from the defname should be avoided because that complicates backward compatibility.

- Making up arbitrary typedefs that have no built-in implementation (hard coded or scripted) could confuse people because it may seem like there is a implementation when in reality there is nothing.

- I left the value as-is because of backward compatibility, but also because it is a base resource for other items, and if a base resource does not have a value, items crafted from it cannot dynamically inherit that value. It should be noted that just because a item has a value, doesn't make vendors buy or sell it (it needs to be in a vendor buy/sell template for that.)