Item plotscript commands

[ohrrpgce-bugbot]

[bz#535]

I think that some of the following commands for manipulating items could be very useful in many endeavors:

use item (itemID) - simple enough. Does no cost checking; use tags defined in item editor and delete item for that.

item in slot (slot number) - return item ID of item in given slot in the inventory, or false if none in that slot.

item count in slot (slot number) - like above, but returns the amount of items in the relevant slot.

read item (itemID,dataslot) - would work much like read NPC, returning relevant data like the item's inbattle attack ID, out of battle attack ID (or negative textbox ID), equippability, stat bonuses (each stat has it's own constant like "itemdata:HPbonus"), and even item name if possible. The only thing that I can see causing serious problems would be who can equip. I guess each hero could be his own constant (itemdata:Hero1canEquip).

Note that if bug bz⁠#516 is fulfilled and we have PS commands to trigger attacks by ID, the 'use item' command is not really needed if we have at least some of the 'read item' command.

From: msw188 Severity: feature request

[ohrrpgce-bugbot]

Comment author: @rversteegen

*** Bug bz⁠#370 has been marked as a duplicate of this bug. ***

[ohrrpgce-bugbot]

Comment author: msw188

*** Bug bz⁠#654 has been marked as a duplicate of this bug. ***

[ohrrpgce-bugbot]

Comment author: @arperry

Voted up, but all I really want is to figure out which attack an item uses.

[ohrrpgce-bugbot]

Comment author: msw188

Having a single command to return an item's attack seems to be a highly inefficient hack. And how would the game know if you meant the inbattle or out-of-battle attack? If this feature is ever implemented, I think it should work as I outlined above for the command "read item". Not only for flexibility, but consistency counts for something too. In a novice programmer's mind, the similarity between "read NPC", "read global", and now "read item" is a desirable quality for Hamsterspeak.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I'll be looking into implementing this as soon as Werewaffle is released.

My plan is to create commands to read and write raw item data, and then to wrap those commands in a series of other commands in plotscr.hsd

I will, of course, need to take caution to implement these generic item data access commands in a way that will not be unnecessarily painful for backwards compatibility in the future, when new features are added to items, and when the .ITM format receives upgrades.

[ohrrpgce-bugbot]

Comment author: @rversteegen

I have a partially complete implementation in my working copy, it's been there for a while. I was going to finish it off and squeeze it into werewaffle (but things don't happen when they could have when you think release's a week away but it never happens) but I still haven't decided on those important problems James mentioned:

The inconsistency between the style, implementation and naming of different sets of commands really annoys me. We've never decided between using read/write commands and a bunch of constants, individual commands, or individual scripts (or even weird mixes, like the enemy commands). I wish we agreed on some consistency. But it seems like which way to go depends on the actual format.

Item data is really heterogeneous, so separate commands or scripts are clearly needed since we have 2 strings, 5 sets of bits, weird and off by one data packings and an array of stats. Arrays of data offset constants won't work when our file formats are this messy, but we could still use lots of constants.

I'm worried that just wrapping data with scripts isn't much use for "backwards compatibility in the future". If the internal format changes, the scripts can't be updated on existing games (well, don't try it). And the scripts won't have access (or not directly) to internal data or functions that might be useful, like updating the hero stats or inventory affected tags.

A sticking point are the item effects: We already have 5 possible item effect: in battle attack, used-as-a-weapon attack, out-of-battle attack, textbox, and teach spell. Bug bz⁠#545 suggests adding a script trigger too. Would this be mutually exclusive to those two? oob attack and textbox are exclusive. I'd have to test to be sure, but doesn't teach spell also override those two? It would be nice to do something like:

get item effect (item, effect) set item effect (item, effect, ID) item effect: textbox #overwrites effect:out of battle attack item effect: out of battle attack #overwrites effect:textbox item effect: in battle attack item effect: weapon attack item effect: teach spell item effect: script define constant (-1, no effect) #'none' is taken?

Are the different overwrites too confusing?

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

The inconsistency between the style, implementation and naming of different sets of commands really annoys me. We've never decided between using read/write commands and a bunch of constants, individual commands, or individual scripts (or even weird mixes, like the enemy commands). I wish we agreed on some consistency. But it seems like which way to go depends on the actual format.

I personally would favor individual commands (regardless of whether those individual commands are implemented individually or implemented as wrappers around a generic read/write pair)

I think the commands that use constants like "alter NPC" feel kinda awkward in regular use.

But ultimately I can't let myself loose too much sleep over the chaos in style and naming, since that chaos is here to stay. We can reorganize the game code, and we can reorganize the file formats, but due to backwards compatibility concerns, plotscripting interfacers are (mostly) here to stay.

The best solution is to read the Principia Discordia, and embrace the Chaos. :)

It would be nice to do something like:

get item effect (item, effect) set item effect (item, effect, ID) item effect: textbox #overwrites effect:out of battle attack item effect: out of battle attack #overwrites effect:textbox item effect: in battle attack item effect: weapon attack item effect: teach spell item effect: script define constant (-1, no effect) #'none' is taken?

Are the different overwrites too confusing?

No, that is actually pretty nifty. I like that interface-- and it does not seem awkward to me in the same way that "alter NPC" constants seem awkward.

Actually, reading your suggestion there makes me suddenly feel much better about the whole thing :)

My only amendment would be:

define constant (-1, item effect: none)

instead of the "no effect" constant

[ohrrpgce-bugbot]

Comment author: @rversteegen

I started on the item commands but saved a patch somewhere and cleaned my working copy. I really should finish it like I promised. (Except it'll be Ypsiliform now)

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

Hey, TMC, you still have a patch for this right? I was about to start working on implementing this when I realized that you had apparently already done all of the work already.

Or if you feel it falls short of being ready for checkin, could you mail me the patch and I'll clean it up and check it in for you?

I'm feeling motivated about items right now, and I hate to waste motivation :)

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

TMC, do you want to check in your patch for this?

If not, I am going to remove it as a ypsiliform stable release blocker, since although item commands would be awesome, they are a feature request and do not affect release-stableness.

[ohrrpgce-bugbot]

Comment author: @rversteegen

Hey, TMC, you still have a patch for this right? I was about to start working on implementing this when I realized that you had apparently already done all of the work already.

Or if you feel it falls short of being ready for checkin, could you mail me the patch and I'll clean it up and check it in for you?

I'm feeling motivated about items right now, and I hate to waste motivation :)

Oh! Sorry for missing this. Anyway, I wasn't close to completing the items commands. And wow, that was over a year ago! I think I have at least a dozen incomplete patchsets!

Lately I've also wondered if we should add items plotscript commands at the moment anyway, instead of rewriting the item system and then adding such commands. Specifically, I think that unique items would be a great feature - such items would in effect have their own item type, created at playtime (with plotscripting). Great for cursing, blessing enchanting, naming, improving, forging, damaging... items! Item commands might be better for considering how this would work first.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I think adding more features to the item system would be great. I think unique items as described in comment 11 would be great.

However, I don't think we should hold up *all* item plotscripting commands for that.

use item (itemID) - simple enough. Does no cost checking; use tags defined in item editor and delete item for that.

item in slot (slot number) - return item ID of item in given slot in the inventory, or false if none in that slot.

item count in slot (slot number) - like above, but returns the amount of items in the relevant slot.

We should implement these three, as well as "set item in slot" and "set item count in slot" right now. TMC, if you don't have check-in-able versions of these commands already, just say the word and I will rewrite them from scratch. I wouldn't mind getting these in before Ypsiliform.

read item (itemID,dataslot) - would work much like read NPC, returning relevant data like the item's inbattle attack ID, out of battle attack ID (or negative textbox ID), equippability, stat bonuses (each stat has it's own constant like "itemdata:HPbonus"), and even item name if possible. The only thing that I can see causing serious problems would be who can equip. I guess each hero could be his own constant (itemdata:Hero1canEquip).

As for this one, I am uncomfortable with it. I know we have other commands that read raw lump data like this, but those are hell for back-compat. A collection of commands for reading and writing each individual item attribute would only be a little more work to implement, and it would be much easier to keep compatible in the future, and would be much less likely to conflict with future extensions to the item format.

I am in no rush to get these in before Ypsiliform, we can take our time and do it right.

[ohrrpgce-bugbot]

Comment author: @rversteegen

I think adding more features to the item system would be great. I think unique items as described in comment 11 would be great.

However, I don't think we should hold up *all* item plotscripting commands for that.

I suggest implementing unique items by creating a unique negatively numbered item type for each unique item. Only question is whether different unique items which are the same should have the same type handle.

use item (itemID) - simple enough. Does no cost checking; use tags defined in item editor and delete item for that.

item in slot (slot number) - return item ID of item in given slot in the inventory, or false if none in that slot.

item count in slot (slot number) - like above, but returns the amount of items in the relevant slot.

We should implement these three, as well as "set item in slot" and "set item count in slot" right now. TMC, if you don't have check-in-able versions of these commands already, just say the word and I will rewrite them from scratch. I wouldn't mind getting these in before Ypsiliform.

Like I said, I don't.

read item (itemID,dataslot) - would work much like read NPC, returning relevant data like the item's inbattle attack ID, out of battle attack ID (or negative textbox ID), equippability, stat bonuses (each stat has it's own constant like "itemdata:HPbonus"), and even item name if possible. The only thing that I can see causing serious problems would be who can equip. I guess each hero could be his own constant (itemdata:Hero1canEquip).

As for this one, I am uncomfortable with it. I know we have other commands that read raw lump data like this, but those are hell for back-compat. A collection of commands for reading and writing each individual item attribute would only be a little more work to implement, and it would be much easier to keep compatible in the future, and would be much less likely to conflict with future extensions to the item format.

I am in no rush to get these in before Ypsiliform, we can take our time and do it right.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

Like I said, I don't.

Oops! You're right, you just said that. Sorry I missed it :)

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

Not a ypsiliform release blocker

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

Okay. The commands to use an item either by item ID number or inventory slot are done.

I still haven't tackled the commands to read item data. I feel like I should probably replace the binary ITM lump with a RELOAD lump before I do that.