Anonymous | Login | Signup for a new account | 25-01-25 07:16 CET |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||
ID | Project | Category | View Status | Date Submitted | Last Update | |
0002215 | SphereServer | script pack | public | 03-10-13 05:12 | 16-10-13 01:51 | |
Reporter | Coruja | |||||
Assigned To | RanXerox | |||||
Priority | normal | Severity | minor | Reproducibility | N/A | |
Status | closed | Resolution | fixed | |||
Platform | OS | OS Version | ||||
Product Version | ||||||
Target Version | Fixed in Version | 0.56c Nightly | ||||
Summary | 0002215: Dragon Scale itemdef properties | |||||
Description | Since 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 Information | t_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 | |||||
Tags | No tags attached. | |||||
Nightly Version | Automated (specify build number) | |||||
Experimental Flags | None | |||||
Option Flags | None | |||||
Internal Build Number | ||||||
Attached Files | ||||||
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 |