Printable View
//All of these are read only and from the first tab of which most cannot be read by ZScript currently
bool IsEquipment //Self explanatory
bool MiscFlags[5] //they vary based off the item class. these are the checkboxes
int Attributes[10] //these are the 10 numerical values that do different things depending on the item class.
IDK about Gleeok, or Saffith, but I support this, and have requested it in the past. It necessitates a quest file format change, which is why it has yet to be added. If added, the editor will need a slight change to turn the ten item attributes into text fields so that all ten can always be defined via scripts, and used with the item editor.
@ZoriaRPG
Didn't think about the editor side of things, but isn't that what the D arguments are for?
This is mainly for reading inaccessible data.
Only partly. It would be very practical to be able to read all of the fields, as that would simplify setting up scripts without hardcoding everything, and might make it practical to establish full custom classes, and use the Attrributes[10] fields for something...anything. At present, anythng with a custom class, locks out those fields on the editor side, which makes them wasted data fields in the struct.Quote:
Originally Posted by Tamamo
Without being able to set those fields in the editor ( a plain numeric value would suffice ), reading them would be effectively pointless, so making it possible to enter values into those fields would be nice.
While you can split the script data (0-9) fields up, to generate more than eight values, that's more useful for arguments that need a wide range of values, rather than setting an attribute out of a list of choices (scripted statements, to read). I tinkered with a automated item-ffc handling script/header, similar to autoghost from ghost.zh, and was restricted to using counter fields, and such, to set values, because we can't use those attributes.
I'm looking at this from an end-user point of view. The average user would much rather just set values in the editor, with a preloaded file that has lots of new goodies, than deal with figuring out which decimal place in D0 does thing a, versus thing b.
To be fair though, it would be good to make most of the values read-write. We can write to this->Power, in itemdata, but the majority of attributes are read-only, which means that modding items on the fly is essentially impossible. If we could do that, we would reduce the number of items required at any one time, dramatically.
Consider items like peril rings, or the lens. Both of these use two attributes, to operate, but we can only write to one of those.
Good point, seems like a good idea.
I need to start asembling a proper list of these things, so that when the project is ready, I remember all this shyte. :p
I was again reminded yesterday that itemdata and weapon vars never want to match up. UseSprite has no itemdata equivalent, and UseSound has no weapon equivalent. If more of them crossed, it would simplify item scripts, and ffc items dramatically. Perhaps trying to ensure that all the properties cross should be in there too.
What I was tryng to do was:
That would have allowed an end-user to use the item editor to mod a class item (in this case, bombs) and have that change afffect a custom, scripted item that creates the same weapon as srcItem, loading the sound, sprites, and other settings from it, rather than specifying them as script args.Code:itemdata it = Game->LoadItemData(srcItem):
this->UseSound(it->UseSound):
Being unable to load the itemdata properties for sfx, sprite, and other very base attributes is certainly a flaw to rectify.