If anything, this example shows, that we cannot just remove /storeItems/ and think its the normal non-store variant. It shows we ALWAYS have to look up typeName.
Yes, DE is wrong, it's surely not our code that's making stupid assumption.
you can't tell me you don't think that's a typing mistake. the client's data have shown REPEATEDLY in the past how…
well, okey. if the data are bad, we are doomed to find more of these annoying bugs anyway. KK. remove the logic.
Bro.
- Normal:
/Lotus/Types/StoreItems/AvatarImages/ImageGaussVED- Store item:
/Lotus/StoreItems/Types/StoreItems/AvatarImages/ImageGaussVED
Ah so im too tired I think its a…
Seems like this item does not have a non-store item counterpart. For some reason
well, it contains /storeitem/ so its a store item? :D
Example:
/Lotus/Types/StoreItems/AvatarImages/ImageGaussVED:)I'd say the data is as close to perfect as it gets, it's just a matter of respecting the 'types'.
But that's a store…
The additional check does harm because
/StoreItems/may be a substring of a non-StoreItem. Also if we assume the data is inaccurate, then we have a lot of other problems.
Why would…
Yea, startingGear uses addEquipment, which does not check for AdditionalItems.
I would like to keep the current way as a sanity check. If for some reason, the data should contain non store items, then the client will bug out receiving them as missionrewards. So, the…
