View Issue Details Jump to Notes ] Issue History ] Print ]
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 
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
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.
Nightly VersionAutomated (specify build number)
Experimental FlagsNone
Option FlagsNone
Internal Build Number
Attached Files

- Relationships

-  Notes
(0001704)
RanXerox (developer)
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 (developer)
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 (developer)
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.)

- Issue History
Date Modified Username Field Change
03-10-13 05:12 Coruja New Issue
04-10-13 18:45 RanXerox Note Added: 0001704
04-10-13 18:45 RanXerox Assigned To => RanXerox
04-10-13 18:45 RanXerox Status new => assigned
05-10-13 18:11 Coruja Note Added: 0001712
16-10-13 01:51 RanXerox Note Added: 0001729
16-10-13 01:51 RanXerox Status assigned => closed
16-10-13 01:51 RanXerox Resolution open => fixed
16-10-13 01:51 RanXerox Fixed in Version => 0.56c Nightly


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker