Nested Clothing

[tajmone]

I've uncovered a new problem with clothing items: when the library initializes clothes carried by the Hero as being worn, it also sets as donned/worn any wearable items nested inside other clothes.

• tests/clothing/class_nested-clothes.a3log

In the tests, a kippah is placed inside the trousers (a kippah is small enough to fit in pants pockets). Tests reveal that the kippah is seen as worn, while it should be just carried.

> examine khakis
A pair of khaki beige cotton pants. Your khakis contain your kippah and 
your wallet.

> DBG khakis
'khakis' VALUES: | botcover: 16 | 
DONNED: Yes 
IN WORN: Yes 
IN WEARING OF: | hero

> ; Inside the trousers (pocket) we have kippah, which is a wearable item.
> examine kippah
It's your kippah. You always carry it around with you.

> DBG kippah
'kippah' VALUES: (none) 
DONNED: Yes 
IN WORN: Yes 
IN WEARING OF: | hero

> ; ** ERROR! ** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ;              The kippah shouldn't be accounted as being worn, but just carried.
> ;              The library needs to check at initialize time that only clothes
> ;              which are DIRECTLY in Hero should be treated as worn items.
> ;              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is probably an easy one to fix, it boils down to handling as worn only clothes which are DIRECTLY in Hero. But once this is fixed, there are many potential problems ahead which need to be tested for:

• What happens if the Hero tries to wear a nested item?
• How are nested clothing handled in NPCs?

Potentially, there are many contexts in which things could break up here. And we're dealing with common cases here, not edge cases — a backpack and woman's bag will probably be implemented as wearables in many adventures; and there are pockets which could contain all sorts of small wearables (glasses, soxes, etc.).

Besides, this problem affects clothing inside any object container carried by the Hero (eg., a box containing a shirt). Basically, right now any clothing inside something else gets seen as worn/donned (probably by NPCs too) the moment an ACTOR posseses the container object.

Due to all the various problems affecting the clothing class right now, we'll need to adress this issue one bit at the time, because there are too many factors at play here.

So, I suggest we start by:

• [ ] looking into INITIALIZE blocks that deal with clothing and ensure that they only account for items DIRECTLY in Hero.
• [ ] Have tests confirm that when the game starts no nested clothing carried by Hero or NPCs are being treated as worn.
• [ ] Then, extend tests to cover complex situations...

[AnssiR66]

Ouch! I will figure out a solution... with all these different shortcomings. My take would be at this point that rather than conjuring new attributes like 'blocked' I would try what can be done with the existing ones. Every new attribute makes the library a bit more complicated to use... (and I think that 'donned' would be sufficient here, because anything that is blocked is also donned...). But I will take a look....

-Anssi

---

From: Tristano Ajmone notifications@github.com Sent: Friday, February 1, 2019 2:20 PM To: AnssiR66/AlanStdLib Cc: Subscribed Subject: [AnssiR66/AlanStdLib] Nested Clothing (#61)

I've uncovered a new problem with clothing items: when the library initializes clothes carried by the Hero as being worn, it also sets as donned/worn any wearable items nested inside other clothes.

• tests/clothing/class_nested-clothes.a3loghttps://github.com/AnssiR66/AlanStdLib/blob/clothing/tests/clothing/class_nested-clothes.a3log

In the tests, a kippah is placed inside the trousers (a kippah is small enough to fit in pants pockets). Tests reveal that the kippah is seen as worn, while it should be just carried.

examine khakis

A pair of khaki beige cotton pants. Your khakis contain your kippah and

your wallet.

DBG khakis

'khakis' VALUES: | botcover: 16 |

DONNED: Yes

IN WORN: Yes

IN WEARING OF: | hero

; Inside the trousers (pocket) we have kippah, which is a wearable item.

examine kippah

It's your kippah. You always carry it around with you.

DBG kippah

'kippah' VALUES: (none)

DONNED: Yes

IN WORN: Yes

IN WEARING OF: | hero

; ERROR! ~~~~~~~~~~~~~

; The kippah shouldn't be accounted as being worn, but just carried.

; The library needs to check at initialize time that ; ~~~~~~~~~~~~~

This is probably an easy one to fix, it boils down to handling as worn only clothes which are DIRECTLY in Hero. But once this is fixed, there are many potential problems ahead which need to be tested for:

• What happens if the Hero tries to wear a nested item?
• How are nested clothing handled in NPCs?

Potentially, there are many contexts in which things could break up here. And we're dealing with common cases here, not edge cases — a backpack and woman's bag will probably be implemented as wearables in many adventures; and there are pockets which could contain all sorts of small wearables (glasses, soxes, etc.).

Besides, this problem affects clothing inside any object container carried by the Hero (eg., a box containing a shirt). Basically, right now any clothing inside something else gets seen as worn/donned (probably by NPCs too) the moment an ACTOR posseses the container object.

Due to all the various problems affecting the clothing class right now, we'll need to adress this issue one bit at the time, because there are too many factors at play here.

So, I suggest we start by:

• looking into INITIALIZE blocks that deal with clothing and ensure that they only account for items DIRECTLY in Hero.
• Have tests confirm that when the game starts no nested clothing carried by Hero or NPCs are being treated as worn.
• Then, extend tests to cover complex situations...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/AnssiR66/AlanStdLib/issues/61, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF2lHgSWPPyZjwZ13RVCkv9SUYOin34iks5vJDEagaJpZM4aeN0f.

[tajmone]

This problem seems to have serious consequences on non-clothing items too. Here are some new tests results:

> examine khakis
A pair of khaki beige cotton pants. Inside the khakis pockets there are 
your kippah and your wallet.

> ; The kippah is stuck in the trousers for it's seen as being worn
> drop kippah
You'll have to take off your kippah first.

> drop wallet
You'll have to take off your wallet first.

> ; ** ERROR! ** The wallet is not worn! (not even a clothing item)
> remove wallet
That's not something you can remove since you're not wearing it.

> ; ** CATCH 22 ** Can't drop it until we remove it,
> ;                Can't remove it 'cos it aint a clothing item!
> empty khakis   ; Only way to take it out is by brute force...
(taking your khakis first)
You empty the contents of your khakis on the ground.

This type of situation is really undesirable in end users adventures, for by turning a bag or a backpack into a wearable clothing item could suddenly disrupt the whole adventure without the author even realizing where the problem is coming from.

The ramifications of the issues surrounding worn items are far fetching. We must definitely find a bullet-proof solution here, which is both elegant and easy for authors to control when extending the library. Otherwise, the price to pay for having built-in clothing fucntionality would be too high to justify the feature.

[tajmone]

(and I think that 'donned' would be sufficient here, because anything that is blocked is also donned...). But I will take a look....

Yes, but not the contrary: not every donned item is blocked, only those which have another item on top of them are.

The point is that the blocked attribute would have to be handled only in wear and remove verbs:

• wear would make an item blocked when another is put on top of it.
• remove would make an item NOT blocked when removing the item on top of it.

If any verbs imply wearing or removing clothes, than they'd have to handle this too (ie, if they remove an item they should unblock the one underneath, and so on).

The reason having blocked might be worth it is because it could cut down considerably the code in all the various places that need to handle worn items.

But much depends on wether EXTRACT is going to be used or not for similar checks. Basically, a blocked item should never be allowed to leave the ACTOR containing it (for it's now only worn, but has another clothing on top of it).

In some execution contexts it might not be possible to access a reference to the containing ACTOR, so checking THIS:blocked would be an alternative mean.

[tajmone]

PS: I gather you're replying to Issues via email, because all your replies contain the full original message after them — which makes the thread very long to navigate.

If you could delete the original thread in your reply messages it would be better, and maybe edit the old replies too.

[AnssiR66]

The layered clothing feature was designed by Alan Bampton long before the standard library adopted that code and he made the tempworn container, for his own purposes of coding. I have never taken a deep enough look to fully grasp what things tempworn actually is used for. At least I can say for sure that it was not designed for the "being worn" message which is my much later inclusion. I would suggest that we leave tempworn be, for the time being. I will take look at the issues revealed so far and let you know my suggestions very soon.

[tajmone]

I will take look at the issues revealed so far and let you know my suggestions very soon.

Ok!

In the meantime, if you're happy with the current tweak for the wear verb I'd like to merge it into master. To keep the history clean I suggest that either:

• I amend the commits in this branch, packing into a single all the tests updated, and into another separate commit changes to the library source, force push the amended branch and merge it into master and then keep it alive for further editing.
• Or I could squash merge it into master as two separate commits, and then delete this branch (which would be out of sync) and create a new one for tests dev.

It's just that I don't like long-living branches because they make working on other features in separate dev branches more complicate (introduce the risk of conflicts to be resolved).

UPDATE — The clothing branch was squashed as two separate commits into master, then master was merged back into clothing so we can still use the branch for testing and postpone its deletion to when we're really done with it and no open issues are pointing to its commits! (this was I've avoided forced pushes, and all the problems that might ensue)

[AnssiR66]

@tajmone You can do whichever is more convenient for you, I guess...