Wanting to add new functionality to all clothes. Its currently not possible to mod/add to ClothingBase to add script functionality as ClothingBase is defined via
typedef Clothing ClothingBase;
Clothing is an engine class which cannot be modded either.
This has become *extremely* important given the changes to CanReceiveItemIntoCargo and CanPutInCargo with 1.08.
A large number of modded items can no longer be used as intended due to restrictions being added that do not consider the wider uses of inventory mechanics; for example, furniture objects with storage containers attached can no longer have items placed into them without first detaching said containers. In addition, modular clothing items with attachable containers can cause the deletion of stored inventory on relog.
Clothing shouldn't be an Engine class so not sure what the problem is there, holds no proto/native methods and inherits from ItemBase which can be modded.
@Jacob_Mango Even though it doesn't make sense why you couldn't, it just doesn't work to mod Clothing class.
The issue of CanReceiveItemIntoCargo is affecting a lot of mods right now. And only way we can fix it is by modding the Clothing function. Or BI can fix their logic in the clothing class at least.
@Geez I bring this to your attention as it's been now quite a while and nothing happened.
I'll bring more light to this issue. The reason this ticket was made was due to a change BI implement to Clothing class. This change was due to a bug i reported: T151500 to avoid allowing players to take items from ground into inventory of clothes that are in cargo of player.
Most of us thought it would just make it easier for us to give us access to have our own rules for clothing but your team can fix it for us instead maybe. 1.09 has brought even more issues with this logic put in place in Clothing class.
1.07 Behaviour:
2 examples->
A.) A storage item (locker) has slot for body (jacket). Player can attach Jacket to the locker and they can add more items inside jacket to store them over time.
B.) )A backpack with an attachment of another container. Player is able to attach this container to the bag and add items to it to carry around.
1.08 Behaviour:
A.) The locker is able to receive the jacket(with or without items inside) in the slot. But the player is not able to add items inside the jacket while it's being attached to the locker.
B.) The bag is able to receive the container(with or without items inside) in slot. But the player is not able to add more items inside the container while it's attached to backpack
For most instances of attachments of type B, players also lost items inside those containers attached to other clothes.
1.09 Behaviour:
Both A and B have same behaviour as before with the exception now it WILL ALWAYS delete or spit out the items from the jacket or container attached to backpack.
To be honest I don't understand why your team went to such lengths to check if the parent is man and if that and that. Seems absolutely pointless.
With the help from MDC I've been able to override the class Clothing and test some things out. These conditions satisfy ALL bugs encountered, including the one I reported during 1.08 experimental. During my tests, there was no loss of items inside cargo. I might have missed something as I'm not perfect either but hopefully we can work together in fixing this. This is causing immense grief to a lot of players and modders.
Please consider both giving us access to amend ClothingBase in a proper way and incorporating these conditions instead of what you have now.
override bool CanPutInCargo( EntityAI parent )
{
bool is_hidden_stash_exception = false;
if ( parent.IsInherited( UndergroundStash ) )
return super.CanPutInCargo( parent );
if ( GetNumberOfItems() != 0)
return false;
return super.CanPutInCargo( parent );
}
override bool CanReceiveItemIntoCargo( EntityAI item )
{
if (GetInventory().IsInCargo())
return false;
return super.CanReceiveItemIntoCargo(item);
}
override bool CanLoadItemIntoCargo(EntityAI item)
{
if (GetInventory().IsInCargo())
return false;
return super.CanLoadItemIntoCargo(item);
}To be honest I don't understand why your team went to such lengths to check if the parent is man and if that and that.
Some mod objects was allowing someting like this: Container inside container attached to container inside container attched to container ...
And I dont think that you want players on your server doing this kind of "experiments". =)
Some mod objects was allowing someting like this: Container inside container attached to container inside container attched to container ...
The checks in question have little to do with nested containers. What they do is allow items with cargo (e.g. clothing) to be attached *only* to entities that are inherited from class Man. That is unnecessary, and breaks functionality of furniture with attachment slots, among other things. Also, checking whether items can be loaded as attachments during load from storage seems... weird, to say the least. If it was saved to storage, then we actually should expect the item to be valid, so why is this additional check there? What problem is it trying to solve? And if it is an actual problem (I have my doubts), why isn't the underlying problem fixed (allowing the item to be attached before saving to storage in the first place, again, if this is indeed a problem)?
And I dont think that you want players on your server doing this kind of "experiments". =)
What server owners put on their modded servers should be their concern. If a mod provides nestable containers, so be it. If you don't like it, don't use it (also, I know of no mod that - deliberately or not - makes containers nestable).
exactly as lava76 said...
These checks are for clothing, not Container_Base. Nesting of containers is very different issue. Even so it shouldn't be so hardly enforced on us.
Nonetheless the "fix" is renabling "bad" modded containers to be nested again, or I`m wrong?
You are wrong. Also, like I said, there's no mods making containers nestable to begin with.
this is affecting clothes only. whether they can take items inside inventory (if in cargo it won't) and if the clothes can be put inside inventory of anything (if it has items inside then you can't put them in another inventory). simplez
Containers themselves (pouches, medkits, etc) are only a factor when they're attached to something that inherits from ClothingBase, as the CanReceiveItemIntoCargo checks go up the hierarchy to parent objects, so if - for example - a bag has a Protector Case attached to it, the Protector Case will return false because its parent - a clothing item - returns false.
Removing the checks *entirely* as my initial solution did allows for nesting (and can be applied to anything, if that's the desired behaviour). Helk's logic fixes the problem entirely, although the logic in CanLoadItemIntoCargo can be omitted for server owners who either a) have previously, or b) wish to permit nesting behaviour that will persist through restarts. Personally, I'd just return true on it for performance reasons myself. I believe it was added as a sort of soft check for DB exploits, as essentially it just sanity checks objects for odd inventory configurations on object load.
Hello everyone.
The issue has been fixed internally and the fix will appear in one of the future updates!
Regards,
Geez
Clothing has been split up into Clothing and Clothing_Base, Clothing extending Clothing_Base, Clothing class being moddable now.
has the logic in CanPutInCargo, CanReceiveItemIntoCargo and CanLoadItemIntoCargo for clothing been revised as well?
We still did not have time to revise the logic of these events yet, and there also is a reason why they are the way they currently are. But it is planned to revise it in the future.
Regards,
Geez
As i thought. Thanks for the reply. The idea behind this ticket was to actually solve the issues that were put in with the logic in these events. We appreciate the change to clothing nonetheless. I will open a new ticket to keep track of the real issue. Solution is simple really and we can work together on it if needed.
Thanks,
Helkhiana.
Thanks for the resolution Geez!
Actually no. I did create this ticket just so I can add clothing specific script without having to to mod itembase. Not saying the issue with events isn't important but it wasn't the reason for this ticket.
The issue has been fixed internally and the fix will appear in one of the future updates!
@borizz.k There has been no update since this was fixed. Be patient.
I got tired - zombies walks through objects textures, loot disappears from containers, cars have to be calmed down form active state on server start.... Bugs, bugs, bugs......
