Simple QOL fixes for item/entity interactions

[beezdul 56]

Here's a list of QOL suggestions to stop scripts from breaking.

Item.interact - Automatically switch to the inventory/equipment/whatever tab when interacting to prevent scripts from messing this up. You can find this bug in some form in almost any script, so an API fix would really help.

GameObject/NPC/groundobject/anything else .interact(string) - if an item is selected, but an action is specified (string) then deselect the item. If an item is selected (through a misclick or something else) and then try to do say, tree.interact("chop") then the client will usually just wiggle the mouse on the tree until logging off or getting stopped.

[Hashtag 8688]

Thanks for the suggestions. Have you tried if getInventory().interact(...) opens the inventory for you? I've heard from Nezz that this is preferred over item.interact.

[Xephy 237]

5 hours ago, beezdul said:

Here's a list of QOL suggestions to stop scripts from breaking.

Item.interact - Automatically switch to the inventory/equipment/whatever tab when interacting to prevent scripts from messing this up. You can find this bug in some form in almost any script, so an API fix would really help.

GameObject/NPC/groundobject/anything else .interact(string) - if an item is selected, but an action is specified (string) then deselect the item. If an item is selected (through a misclick or something else) and then try to do say, tree.interact("chop") then the client will usually just wiggle the mouse on the tree until logging off or getting stopped.

If an Item.deselect is inherently implemented, then it may mess up scripts that make use of this to use items on an entity without the Item.useOn method. To further add onto this suggestion though, I would like to see a random solver for the world map being open implemented because sometimes Item.deselect will open the world map iirc.

[beezdul 56]

1 hour ago, Xephy said:

If an Item.deselect is inherently implemented, then it may mess up scripts that make use of this to use items on an entity without the Item.useOn method.

What if this only applied when the action is unspecified or "Use"?

[Nuclear Nezz 2051]

8 hours ago, beezdul said:

Here's a list of QOL suggestions to stop scripts from breaking.

Item.interact - Automatically switch to the inventory/equipment/whatever tab when interacting to prevent scripts from messing this up. You can find this bug in some form in almost any script, so an API fix would really help.

GameObject/NPC/groundobject/anything else .interact(string) - if an item is selected, but an action is specified (string) then deselect the item. If an item is selected (through a misclick or something else) and then try to do say, tree.interact("chop") then the client will usually just wiggle the mouse on the tree until logging off or getting stopped.

item.interact is simply that, item.interact

If you wish the tab to automatically open, use getThing().interact, that will open the tab. Inventory, Equipment, etc. We don't have separate items for separate containers, and unless we rewrote them to be such, we have no way of knowing which item you're interacting with, short of searching all containers until we found it. In such a case, if you had the same item in equipment and inventory, which would you want to be interacted with? Specification through our API is the easiest and least costly route. (eg: getInventory().interact and getEquipment().interact)

 

And what if they just do interact()? I know more than a few use that, rather than specifying the action. We can't determine what they're trying to do if they don't tell us.

Though yes, if they pass in an action that is not "Use" and they have an item selected, we could deselect it. At the same time, I feel like that's something that a scripter should be handling if they're doing things that may result in an item being selected.

If others agree that we should be checking the action and item.isselected, then sure I'm happy to add it, but it feels like adding in an extra call to something that only happens rarely, and only in cases where you're interacting with items often enough that it may select one on accident.

3 hours ago, Xephy said:

If an Item.deselect is inherently implemented, then it may mess up scripts that make use of this to use items on an entity without the Item.useOn method. To further add onto this suggestion though, I would like to see a random solver for the world map being open implemented because sometimes Item.deselect will open the world map iirc.

I may look into having more specific areas that it will click to deselect an item using deselect() like clicking on the item itself that was selected. I'll play around with it a bit, if you have any suggestions on where a better place to click would be, let me know.

I'm not sure about adding in a full random solver for the world map, again that's a lot of extra calls and checks for something that rarely happens. You have to remember the random solvers run on a separate thread and are always being checked, to re-check the widgets that often can lead to an unnecessary increase in CPU.

 

 

I do appreciate the suggestions though. I apologize if my response to your first suggestions are not positive, that doesn't mean I don't listen to them.

 

Edit: For the deselect, I'm just going to change it to open menu->cancel, that deselects items from what I can tell. Not sure why this wasn't a thing to start with.