search

AnssiR66 / AlanStdLib

The Standard Library for ALAN Interactive Fiction Language
Other
6 stars 2 forks source link

Clothing Table: Coveralls #52

Closed tajmone closed 5 years ago

tajmone commented 5 years ago

Ciao Annsi,

This week I'm working on testing and documenting the libary clothing system. I'm struggling a bit to work out some details, so I need to ask you a few questions, especially regarding the clothing table.

Some confusion might be due to clothing items terminology of the table, which has often different meaning in UK and US English (I'm assuming that UK English is the standard here, as it makes more sense for most examples).

Clothing Headcover Topcover Botcover Footcover Handcover
teddy 0 4 4 0 0
blouse/shirt/T-shirt 0 8 0 0 0
dress/coveralls 0 8 32 0 0
skirt 0 0 32 0 0
trousers/shorts 0 0 16 0 0

Coveralls

The values proposed by the Clothing Table for coveralls are the same as those for a dress (top 8, bot 32). I have the impression that coveralls should have a botcover value of 16 (like trousers), instead of 32 (like skirt).

The code in the wear and remove verbs, when dealing with legs it discounts a clothing item with botcover 32, assuming it's a skirt-like item that doesn't prevent wearing a legs-only item. While this might be true for a skirt and a dress, I can't see how it should apply to coveralls, for these are trousers like clothing:

Shouldn't coveralls have values top cover 8 and botcover 16? i.e. be treated as if the hero is wearing a shirt and trousers?

If I've understood correctly, the code checks wether the hero can wear the item according to the currently worn clothes. I'm not sure wether one can wear trousers or not underneath a coveralls — probably depends on the type of coverall suit, as they come in different types.

AnssiR66 commented 5 years ago

Yes, I can see your point. However, I would picture coveralls as an outfit you can put on top your trousers and shirt, like a work uniform on construction sites etc. I wouldn't necessarily see a problem with how the table defines them presently.. then again, coveralls can be also other kind than a work uniform. My gut feeling would be that there is no urgent need to change the numbering... but please, do make your counter-argument if you feel this is not defined in an intuitive way, we can still think about it...

tajmone commented 5 years ago

Probably the best thing here is to create some extensive tests for clothing, covering a wide variety of common and less common clothing items (currently working on it locally) so we can have some real cases to discuss.

Most likely, it just boils down to the Clothing Table needing some more explanations — especially since its terminology means different things in UK and USA English. But that could be addressed in Clothing Guide.

then again, coveralls can be also other kind than a work uniform.

Indeed, it's a very broad term.

I would picture coveralls as an outfit you can put on top your trousers and shirt,

From what I gather from studying the code, the issue here is that skirts were implemented to allow wearing trousers (or legs underwear) without having to remove the skirt, based on the assumption that (as long as the item being worn doesn't involve the area above the waist) lifting the skirt provides access to the bottom part. This being a feature/value shared with coveralls it ensues that also wearing/removing trousers while wearing coveralls is currently possibe — this being my concern here, since this wouldn't be possible in real life.

But again, better test this.

Also, I'd like to create tests for more complex clothing items and see how they are dealt with — eg.:

And, of course, how ornamentals like watches, necklaces, rings, bracelets, ties, etc. can be handled (ie., if having all attributes set to zero does the job). After all, these should be wearable like any other clothing, but without restrictions (one could wear multiple rings, bracelets and necklaces, although wearing multiple ties doesn't make much sense).

AnssiR66 commented 5 years ago

You raised a good point about watches, necklaces, rings, etc. Some would probably need a numerical attribute as well (and not just zero): for example, you cannot put on a ring if you are wearing gloves, etc. A ring should probably be handcover 2, then again there are some items that wouldn't need a numerical attribute, such as a necklace probably... but could you put on a necklace if you are wearing a scarf? (but a scarf is not in the clothing table, either). Probably some of these cases might be too nitpicking to matter. To be honest, I don't have a clear definite idea of the coveralls beyond that some testing is needed;, like you suggested on the other hand, as it is a broad term, should there just be an instruction in the manual about it, and not include it readily in the clothing table? ...

-Anssi

From: Tristano Ajmone notifications@github.com Sent: Saturday, January 19, 2019 11:24 AM To: AnssiR66/AlanStdLib Cc: AnssiR66; Comment Subject: Re: [AnssiR66/AlanStdLib] Clothing Table: Coveralls (#52)

Probably the best thing here is to create some extensive tests for clothing, covering a wide variety of common and less common clothing items (currently working on it locally) so we can have some real cases to discuss.

Most likely, it just boils down to the Clothing Table needing some more explanations — especially since its terminology means different things in UK and USA English. But that could be addressed in Clothing Guide.

then again, coveralls can be also other kind than a work uniform.

Indeed, it's a very broad term.

I would picture coveralls as an outfit you can put on top your trousers and shirt,

From what I gather from studying the code, the issue here is that skirts were implemented to allow wearing trousers (or legs underwear) without having to remove the skirt, based on the assumption that (as long as the item being worn doesn't involve the area above the waist) lifting the skirt provides access to the bottom part. This being a feature/value shared with coveralls it ensues that also wearing/removing trousers while wearing coveralls is currently possibe — this being my concern here, since this wouldn't be possible in real life.

But again, better test this.

Also, I'd like to create tests for more complex clothing items and see how they are dealt with — eg.:

And, of course, how ornamentals like watches, necklaces, rings, bracelets, ties, etc. can be handled (ie., if having all attributes set to zero does the job). After all, these should be wearable like any other clothing, but without restrictions (one could wear multiple rings, bracelets and necklaces, although wearing multiple ties doesn't make much sense).

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/AnssiR66/AlanStdLib/issues/52#issuecomment-455763843, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF2lHozPwcrAjTHRm3mDvrBMzfQP1mQbks5vEuRcgaJpZM4ZYS8e.

tajmone commented 5 years ago

could you put on a necklace if you are wearing a scarf?

Well, as long as such ornamentals are wearable (ie. nothing in the current code prevents it) I'd say it's fine — the player would assume that it's just being done in the background, somehow. What really matters here (IMO) is preventing wearing more than one pair of trousers, hats, etc.; but ornamental items should be just fine.

Eeven wearing a ring while wearing gloves ... we could assume the main characters quickly removes the glove and puts back on. Unlike other clothing items which imply getting undressed in public, removing a scarf or a glove is something that could be done in public places without being an out-of-order behaviour (not so removing one's trousers or even a shirt).

should there just be an instruction in the manual about it, and not include it readily in the clothing table?

The original issue was about either removing coveralls from the table or testing alternative values for it (as it is currently, it seems wrong due to the skirt conflict mentioned).

But defintely there is a need for more instructions — which is the idea behind the Clothing Guide document I'm workin on. Right now, I'm really struggling with clothing in the Italian library, for I'm not fully understanding how the system works and what to expect. The problem is that I'm unable to translate the terminology used in the clothing table because these terms yeld different results in UK and US English, and I have to try and guess which one matches the values in the table.

The most problematic items so far are: teddy, dress and coveralls. In some cases, the examples covers clothing items only for one gender (teddy), and I'm trying to find examples for the other gender too (eg. a union suit). Also, for many such items is not very clear wether underware could be worn underneath them or not (teddy, union suit) for the degin of these items has changed in the course of time.

Ideally, the Clothing Guide document could provide practical image examples of the various items, as well as some example code. This would also allow us to do some extended tests on clothing items and allow us to revise the Clothing Table.

I've actually started to work on clothing tests in a local branch, I just haven't managed to complete it. So, I should carry on with the tests example, and publish the branch so we can look at some live code and comment on it. I'll try to do it today or tomorrow.

tajmone commented 5 years ago

Clothing Tests Branch

Ok, I've finally managed to polish enough the clothing tests I was working on and publish them on a temporary branch (not to be merged):

https://github.com/AnssiR66/AlanStdLib/tree/clothing-tests-prep/tests

Overalls/Skirt Problem

As the current test log confirms, the current values for overalls in the Clothing Table are problematic:

> wear dungarees
You pick up the dungarees and put them on.

> ; ** ERR!!! ** Coveralls should prevent wearing other legwear:
> wear pantyhose
You put on the white pantyhose.

So, the values for overalls in the Clothing Table need to be rethinked.

Also, I'm not sure if this is intended or not, but while wearing a skirt only legware with a value botcover <= 8 can be worn:

> wear skirt
You pick up the skirt and put it on.

> wear pantyhose
You pick up the white pantyhose and put them on.

> ; ** ERR??? ** Is this an error or is it intended to be so?
> wear jeans
You pick up the jeans. You're already wearing a pair of white pantyhose 
and a skirt. Trying to put the jeans on isn't very sensible.

Since skirt has botcover 32, and trousers 16, shouldn't wearing trousers under a skirt be allowed? The code comments state:

--------------------------------------------------------------------
-- Now discount any dress/ skirt coverall like clothes as these do
-- not technically affect ability to put on lower body only clothes.
-- Special clause here excludes the full body coverage 'teddy' type
-- garment - as a skirt WOULD prevent that from being removed.
-- ( dress/coat garments automatically prevent this by virtue of
-- having higher 'topcover' settings than the teddy )
--------------------------------------------------------------------

where it mentions "lower body only clothes", which should mean any legwear with botcover <= 16 in my understanding. Since these values are abstract representations of clothing items, they could refer to a wide variety of clothes (ie not only trousers).

Redundancy in Wearing Reports

Also, messages listing worn clothing tend to be redundant:

> wear jeans
You're already wearing a pair of white pantyhose (being worn) and a pair
of dungarees. Trying to put the jeans on isn't very sensible.

ie: "You're already wearing ... (being worn)". Also, notice that the dungarees are not being mentioned as worn in the message!

In the Italian library I had removed the "(being worn)" part, which is defined in lib_messages.i and is only used in this library output:

  CONTAINS_COMMA: "$01"
    IF parameter1 ISA CLOTHING
      THEN
        -- the following snippet adds "(being worn)" after all
        -- pieces of clothing worn by an NPC, at 'x [actor]'

        IF parameter1 IS donned
          THEN
            IF parameter1 NOT IN worn
              THEN "(being worn)"
            END IF.
        END IF.
    END IF.
    "$$,"

I've just stripped off the whole CLOTHING IF-block.

tajmone commented 5 years ago

Test Clothing Edge Cases

Ok, I've started testing wearable ornamentals and clothing items without values:

You raised a good point about watches, necklaces, rings, etc. Some would probably need a numerical attribute as well (and not just zero): for example, you cannot put on a ring if you are wearing gloves, etc. A ring should probably be handcover 2, then again there are some items that wouldn't need a numerical attribute, such as a necklace probably... but could you put on a necklace if you are wearing a scarf? (but a scarf is not in the clothing table, either).

This is exactly the type of issue that I'm facing while testing, and I'm trying two approaches: no values and using extra-layers.

Using Extra Layers

In the "sports department" I'm trying to implement some skiing clothing and gear. For example, balaclava and ski goggles are implemented with headcover 2 and 4, respectively, to allow wearing one on top of the other and prevent wearing multiple items of the same type.

> dbg balaclava
'balaclava' VALUES: | headcover: 2 |

> dbg ski goggles
'ski goggles' VALUES: | headcover: 4 |

> ; Ski goggles should be wearable on top of a balaclava.
> wear balaclava
You pick up the balaclava and put it on.

> wear goggles
You pick up the ski goggles and put them on.

> inv
You are empty-handed. You are wearing your socks, your boxers, your 
undershirt, your sneakers, a pair of ski goggles and a balaclava.

The problem here is that the face area and the head are treated as one, so this would prevent wearing also a hat (at least, not without complications).

Valuless Clothing Items

I've also tested watches and scarfs as valueless items. This works fine but, as you foresaw, nothing prevents wearing multiple items of the same type:

> dbg watch
'sports watch' VALUES: (none)

> wear it
You pick up the sports watch and put it on.

> ; WEAR MULTIPLE SCARFS:
> wear white scarf
You pick up the white scarf and put it on.

> wear blue scarf
You pick up the blue wool scarf and put it on.

> wear black scarf
You pick up the black scarf and put it on.

> inv
You are carrying a balaclava. You are wearing a white scarf, a blue wool
scarf, a black scarf, your socks, your boxers, your undershirt, your 
sneakers, a sports watch and a pair of ski goggles.

Problem or Not?

Probably some of these cases might be too nitpicking to matter.

I wouldn't bet on this. As the skiing example shows, even not-so-out-of-the-ordinary clothing items can pose a challange in the present implementation. Glasses, in general, are a common wearable item. Also, depending on the setting of an adventure (cold or warm place) some clothing might become ordinary — in cold settings scarfs would be a common item.

Fantasy and Sci-Fi adventure might require lots of wearables (from space suits to medallions and amulets). Historical simulations might require all sorts of unusual clothes. And so on. So we can't really give for granted any fixed model when it comes to clothing.

I think this is a bit of a delicate area since every author will have his/her own vision of which would be a proper way to implement clothing (if clothing is a requirement at all). In my experience, authors usually prefer freedom of choice when it comes to:

Optional Modularity, Possible?

The main issue I see here is that since clothing is integrated into the library, this could easily become a problem.

Ideally, the whole clothing classes and verbs should be in a standalone module that could be optionally included in an adventure, or just left out (in case not required at all, or if it doesn't meet the needs of a particular adventure). This way, author could implement their own clothing system to meet their needs.

But plug-in modularity doesn't seem easy to achieve in Alan. From what I understand, you can't have multiple ADD TO or INITIALIZE for a same class, which makes modularity difficult to manage. I've given quite a lot of thought to the whole idea of making some modules optionally pluggable in, but I soon realized it might not be as easy as one might expect. Proably it would require usage of conditional blocks and includes in various places (classes definitions, INITIALIZE and ADD TO blocks), leading soon to complexity.

Expanding The Clothing System?

I've also tinkered with the idea of revising the clothing coverage attributes and (although I haven't yet come up with a clear cut solution) it looks like a possible solution could be adding separate attributes for each zone, to control if an item blocks the layers below and above it.

A very sketchy example:

-- A backpack, which would prevent wearing a coat due to its bulk:
HAS top_cover: 32.       -- body area of wearing.
HAS top_block_below: 32. -- prevents wearing/removing from 32 downward.
HAS top_block_above: 32. -- prevents wearing from layer 32 upward.

-- A skirt, doesn't prevent wearing legwear:
HAS bot_cover: 32.       -- body area of wearing.
HAS bot_block_below: 0.  -- doesn't prevent wearing/removing lower layers.
HAS bot_block_above: 32. -- prevents wearing from layer 32 upward.

... this probably wouldn't actually work in real cases, but it shows the idea that additional attributes could be employed to handle blocking lower and upper layers (separately). Some bulky items might prevent wearing anything else on top of them.

Although this approach would introduce many new attributes, as long as the defaults work for most clothes only the exceptions would have be manually declared (e.g. a skirt that doesn't block lower layers, or a backpack that block upper ones).

Basically, the special cases that the library handles by hard-coding special clothing like skirt and teddy, should be instead handled by customizable attributes.

What makes the whole clothing thing an ordeal is the lack of bitwise operations in Alan — bit manipulation would simplify a lot these checks.

Also, while the Clothing Table offers useful guidelines, the problem is that the StdLib currenly hardcodes mapping some layers to specific clothing items (skirt and teddy). Depending on the actual adventure, some layers might be used differently.

For example (assuming we had a facecover attribute), the presence of a balaclava in the game might require using a facecover=2 for the balaclava, and facecover=4 for goggles/glasses; while usually facecover=2 would be usable for goggles. I.e., layers assignment depends on the actual needs, but for consistency sake all clothing items should adopt the same convention in every adventure.

IMO, the current hard-mapping of layers should be unconstrained, at the cost of introducing extra attributes that would allow authors to control edge cases like skirts.

AnssiR66 commented 5 years ago

OK, many of these special cases might be possible to handle with the author taking into account these cases individually -

THE pants ISA CLOTHING VERB wear DOES ONLY IF skirt IN wearing Of hero THEN "You can't put them on while you're wearing the skirt." ELSE "You put on the pants." INCLUDE pants IN wearing OF hero. END IF. END VERB. END THE.

but this, of course, is only extra work for the author who expects that the numerical attributes will do the job.

So, my take on this whole problem would be that the manual should instruct the author to use the attributes 2,4,8,16, 32 or 64 intuitively and not look blindly at the clothing table: the items of clothing that are allowed closest to the skin should be a of course a low number (2) and the order that the author intends to allow the clothing to be worn should be reflected in these numbers, regardless of the exact value in the clothing table. So, whereas ski goggles would be usually 2, a balaclava (value 2) would force the goggles to be 4 instead, a hat worn together with these items would be 8, etc.

A skirt would be 2 (would be much more straightforward than "bot_block_below 32") if nothing is meant to be worn under it, or 4 if legwear is supposed to go under, (and then the legwear would be 2) etc. The skirt doesn't have to be 32 even if the table says so. Similarly, we can assign the value 64 to a piece of clothing that shouldn't take anything else on top of it:

THE swimming_pants ISA CLOTHING HAS botcover 2. END THE.

VErb swim DOES MAKE swimming_pants botcover 64. END VERB. -- nothing can be put on top of the swimming pants while they are wet, etc. (it doesn't have to be exactly 64, of course, but just the highest number compared to any other botcover clothing items in the game)

(Or, to ensure that nothing can be worn on top OR under the swimming pants while they are botcover 64, make all other botcovers in the game the same value as the swimming pants, temporarily, and so on.)

In summary, my suggestion: we make clear in the manual that the clothing values in the table are suggestive, and that the table is only there to give a default suggestion, but the author's need to block something to be worn should be guided by the relative assigning of the numerical attributes, particularly when the author needs to implement clothing that behaves differently from what the table assumes, or when there are pieces of clothing that are not mentioned in the table. I would be against introducing new attributes which make the library more complicated, when these numerical attributes can do the job... but what do you think?

-Anssi

From: Tristano Ajmone notifications@github.com Sent: Thursday, January 24, 2019 1:14 PM To: AnssiR66/AlanStdLib Cc: AnssiR66; Comment Subject: Re: [AnssiR66/AlanStdLib] Clothing Table: Coveralls (#52)

Test Clothing Edge Cases

Ok, I've started testing wearable ornamentals and clothing items without values:

You raised a good point about watches, necklaces, rings, etc. Some would probably need a numerical attribute as well (and not just zero): for example, you cannot put on a ring if you are wearing gloves, etc. A ring should probably be handcover 2, then again there are some items that wouldn't need a numerical attribute, such as a necklace probably... but could you put on a necklace if you are wearing a scarf? (but a scarf is not in the clothing table, either).

This is exactly the type of issue that I'm facing while testing, and I'm trying two approaches: no values and using extra-layers.

Using Extra Layers

In the "sports department" I'm trying to implement some skiing clothing and gear. For example, balaclava and ski goggles are implemented with headcover 2 and 4, respectively, to allow wearing one on top of the other and prevent wearing multiple items of the same type.

dbg balaclava

'balaclava' VALUES: | headcover: 2 |

dbg ski goggles

'ski goggles' VALUES: | headcover: 4 |

; Ski goggles should be wearable on top of a balaclava.

wear balaclava

You pick up the balaclava and put it on.

wear goggles

You pick up the ski goggles and put them on.

inv

You are empty-handed. You are wearing your socks, your boxers, your

undershirt, your sneakers, a pair of ski goggles and a balaclava.

The problem here is that the face area and the head are treated as one, so this would prevent wearing also a hat (at least, not without complications).

Valueless Clothing Items

I've also tested watches and scarfs as valueless items. This works fine but, as you foresaw, nothing prevents wearing multiple items of the same type:

dbg watch

'sports watch' VALUES: (none)

wear it

You pick up the sports watch and put it on.

; WEAR MULTIPLE SCARFS:

wear white scarf

You pick up the white scarf and put it on.

wear blue scarf

You pick up the blue wool scarf and put it on.

wear black scarf

You pick up the black scarf and put it on.

inv

You are carrying a balaclava. You are wearing a white scarf, a blue wool

scarf, a black scarf, your socks, your boxers, your undershirt, your

sneakers, a sports watch and a pair of ski goggles.

Problem or Not?

Probably some of these cases might be too nitpicking to matter.

I wouldn't bet on this. As the skiing example shows, even not-so-out-of-the-ordinary clothing items can pose a challange in the present implementation. Glasses, in general, are a common wearable item. Also, depending on the setting of an adventure (cold or warm place) some clothing might become ordinary — in cold settings scarfs would be a common item.

Fantasy and Sci-Fi adventure might require lots of wearables (from space suits to medallions and amulets). Historical simulations might require all sorts of unusual clothes. And so on. So we can't really give for granted any fixed model when it comes to clothing.

I think this is a bit of a delicate area since every author will have his/her own vision of which would be a proper way to implement clothing (if clothing is a requirement at all). In my experience, authors usually prefer freedom of choice when it comes to:

Optional Modularity, Possible?

The main issue I see here is that since clothing is integrated into the library, this could easily become a problem.

Ideally, the whole clothing classes and verbs should be in a standalone module that could be optionally included in an adventure, or just left out (in case not required at all, or if it doesn't meet the needs of a particular adventure). This way, author could implement their own clothing system to meet their needs.

But plug-in modularity doesn't seem easy to achieve in Alan. From what I understand, you can't have multiple ADD TO or INITIALIZE for a same class, which makes modularity difficult to manage. I've given quite a lot of thought to the whole idea of making some modules optionally pluggable in, but I soon realized it might not be as easy as one might expect. Proably it would require usage of conditional blocks and includes in various places (classes definitions, INITIALIZE and ADD TO blocks), leading soon to complexity.

Expanding The Clothing System?

I've also tinkered with the idea of revising the clothing coverage attributes and (although I haven't yet come up with a clear cut solution) it looks like a possible solution could be adding separate attributes for each zone, to control if an item blocks the layers below and above it.

A very sketchy example:

-- A backpack, which would prevent wearing a coat due to its bulk:

HAS top_cover: 32. -- body area of wearing.

HAS top_block_below: 32. -- prevents wearing/removing from 32 downward.

HAS top_block_above: 32. -- prevents wearing from layer 32 upward.

-- A skirt, doesn't prevent wearing legwear:

HAS bot_cover: 32. -- body area of wearing.

HAS bot_block_below: 0. -- doesn't prevent wearing/removing lower layers.

HAS bot_block_above: 32. -- prevents wearing from layer 32 upward.

... this probably wouldn't actually work in real cases, but it shows the idea that additional attributes could be employed to handle blocking lower and upper layers (separately). Some bulky items might prevent wearing anything else on top of them.

Although this approach would introduce many new attributes, as long as the defaults work for most clothes only the exceptions would have be manually declared (e.g. a skirt that doesn't block lower layers, or a backpack that block upper ones).

Basically, the special cases that the library handles by hard-coding special clothing like skirt and teddy, should be instead handled by customizable attributes.

What makes the whole clothing thing an ordeal is the lack of bitwise operations in Alan — bit manipulation would simplify a lot these checks.

Also, while the Clothing Table offers useful guidelines, the problem is that the StdLib currenly hardcodes mapping some layers to specific clothing items (skirt and teddy). Depending on the actual adventure, some layers might be used differently.

For example (assuming we had a facecover attribute), the presence of a balaclava in the game might require using a facecover=2 for the balaclava, and facecover=4 for goggles/glasses; while usually facecover=2 would be usable for goggles. I.e., layers assignment depends on the actual needs, but for consistency sake all clothing items should adopt the same convention in every adventure.

IMO, the current hard-mapping of layers should be unconstrained, at the cost of introducing extra attributes that would allow authors to control edge cases like skirts.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/AnssiR66/AlanStdLib/issues/52#issuecomment-457160668, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF2lHvQmnh4ApsUjNFf8v4Hs-t4j1GKYks5vGZWqgaJpZM4ZYS8e.

tajmone commented 5 years ago

Ciao Annsi,

I like your proposal.

I'm also assuming that this would entail removing the special handling of skirt and teddy discounting in the library source, leaving authors to handle such special cases. (this part of the code being the main obstacle here, and a problematic one too when it comes to overalls.)

I think it's worth it. The library would then provide a simple multilayer clothing system that implies wearing/removing each item in the correct order, but then leave it to the author and his/her needs to decide how to use those layers.

This would mean that an author could focus only on armors (ignoring underwear), another on finer-grained details like underwear, shirts, coats, etc. — whichever the need, having 6 layers at their disposal (ie: 2, 4, 8, 16, 32 and 64) should be enough for most use scenarios.

I don't think that ensuring that a skirt should allow wearing under-layers (with the exception of a teddy) is soo important a feature after all — not if it comes at the cost of precluding a whole range of customizations. And authors could handle these cases (if they really want to) by adding extra attributes themselves, or custom verbs overrides, etc. The worst case scenario is that a skirt would have to be removed to wear leggins, etc. (which is not a big deal).

Also, the whole layer system could be treated as optional by authors, they'd only have to create clothes without any coverage values at all. In some cases this might even be OK, e.g. when there are only a few magic wearable items in a game (a mantel, a crown, etc.).

The Clothing Table would then become just an example reference to help authors understand the system, but by no means a fixed thing (which currently is, due to teddy and skirt). Indeed, authors do need to understand the layered clothing in detail in order to know how to use it properly — and I admit having struggled so far, precisely due to the special handling of skirts and teddies.

As your example of the wet costume demonstrated, the real use scenarios are just too wide to be predictable (temperature could be a preventing factor in wearing/removing items too), so the nitty-gritty details are best left open for authors to deal with. I like your suggestion of changing the coverage values during game, didn't think of that! (and, again, a good example of why skirt exceptions should be removed from the code maybe).

So, whereas ski goggles would be usually 2, a balaclava (value 2) would force the goggles to be 4 instead, a hat worn together with these items would be 8, etc.

I think that adding an extra facecover attribute for the face might be worth it — headcover being more useful for hats (and other things that go on top of the head), while facecover could deal with glasses, masks, fake beards, blindfolds, etc. — and a balaclava would cover both head and face. I know it's impossible to map the whole body, but the face is indeed an important part of the body (actually, the most important one when it comes to relations), and the skiing gear examples showed that distinction between headwear and facewear might be useful.

I can't help thinking that IF games are all about adventures more than real life, so the unlikely is going to be common place therein. Fantasy being the only limit here, it's hard to imagine all the props that could come into being — but surely hazmat suits and gas masks are cheap in the IF world, and extreme environments are always round the corner in the realm fiction, from nuclear holocausts to space journeys, anything becomes possibile (and without added material costs).

tajmone commented 5 years ago

ISSUE CLOSURE NOTE — The changes to the clothing system introduced in StdLib 2.2 solve the issues mentioned here, for special clothes will no longer be hardcoded to fixed layers.