Compass and Map type items conflict with "Can_Player_Equip true"
Opened this issue · 6 comments
Adding "Can_Player_Equip true" to Compass or map type items doesn't actually allow equipping these items, but still causes a Dequip button to appear in their item card UI. Supply type didn't really work for me either.
I know that the Docs obviously state that Compass and Map type items are unequipable, but "Can_Player_Equip true" property seems as a way to brute force this capability onto other types of items that never were equipable in the vanilla game, so I think its fair to consider this a bug.
P.S.
The reason I'm reporting this is that I managed to make a physical compass item, that always points towards the North, and the idea was that you could use it both as a vanilla compass, and a physical immersive one, in case the server its used on has UI turned off, or maybe for some kind of videos, and this bug really ruins the whole idea : /
Its just that many of these reports get dismissed as "Unintended" because there's no use for it in the vanilla game, even though either the Docs or some other sources state that its supposed to work in some way, and it doesn't, but I think at least the "Can_Player_Equip true" should be able to make any item equipable, or else, there isn't much point in it except for just making one type (Supply) of item equipable, that previously wasn't equipable.
Also Compass and Map item types really seem quite redundant. Perhaps you could just make it that "Enables_Compass", "Enables_Map" and "Enables_Chart" are available for any item type, and just change the vanilla ones to Supply type, if it doesn't require some kind of major rewrite?
The original reason it was added was so that modders could disable the ability to equip an item. Specifically, some curated maps have sentry-only weapons. An item isn't properly useable with a useable type. I'll update the docs to reflect this, given it's definitely a very important clarification, sorry. :(
If the docs state something is to supposed to work in some way (but doesn't)—or doesn't provide important context about how a property behaves—, please create an issue on the Unturned-Docs repo! I'd really appreciate it.
I'm not sure what the "dismissed reports" is referring to, but a lot of issues get closed for being feature suggestions, rather than bug reports. Those shouldn't be posted as an issue. They can still be posted elsewhere (such as on our forum, or in the "Discussions" section)!
This falls more into semantics at this point, but I'ld argue that a feature request would be asking for something brand new, while this , is just asking for a Tag, or some property, to meet the expectations, judging on how its written. A recent example would be my bug report of Carepackage script (and, since its the same code used) airdrop code causing issues if the barricade specified isn't a Storage type, while in the Carepackage script the ID field says "Barricade ID", instead of Storage ID or something like that.
Or, when it comes to this exact report, its not just the Docs description that throws you off when inquiring about "Can_Player_Equip bool", but also the way that its written. You'ld assume if you can set it to "false", you should be able to set it to true too. If it was written as "Unequipable" tag without any additional variable required, like "Traction" for vehicles, or "Hook_Sight" for guns, if you get what I mean. You just state these in your asset, and they start working, and you dont assume, that you can set them to a different value and get an opposite outcome, like most people would with bool type tags that we have in the game.
But I guess the most important principle in this for me isn't just the way we speak of it or anything like that. I just believe that its only natural, that lower classes should inherit most of the properties of their parent classes. I mean, I'm no programmer, but I'ld assume thats the entire point of having object-oriented coding languages, like the one Unity and Unturned use? Its just that notice a lot of these instances, where a property of some class isn't properly inherited, like in this case, and from this point of view I am obviously considering it a bug. From this point of view, feature request would be adding new tags and functionality to classes, while spreading the use of already existing ones, especially from Parent class to a child class is only natural, and if its not a bug fix, its at the very least quality of life update, I guess.
I'm not trying to prove anything here, I just decided to explain the way I see it, and why I make this kind of reports, and perhaps point out why its important.
It's understandable that it'd be frustrating when it doesn't work in the way its name might suggest.
Molt's explanation of the technical reasoning is accurate. (Thanks!)
It might work to make it equipable by setting Useable to SDG.Unturned.Useable which is the base useable class without any functionality.
It might work to make it equipable by setting Useable to SDG.Unturned.Useable which is the base useable class without any functionality.
Well, the thing is that as far as I can tell Useable property of items does not support direct type referencing, and it can only use aliases set within UnturnedNexus class, and it doesn't have an alias for SDG.Unturned.Useable. Maybe as a workaround it could be added to the next update? So that modders can just write "Useable Useable" or "Useable Base" or something more fitting.
Ah, you're right, thanks iBowie! I thought it currently allowed a type fully qualified name similar to the asset "Type" property.
(For the time being, the Useable and Can_Player_Equip properties have had their descriptions updated to better explain how equippable items function. Sorry again!)