hectic1
-
Posts
49 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by hectic1
-
-
2 hours ago, Da5id Weatherwax said:
With respect, I'm afraid you are wrong. These are not apples and oranges..
avatar+hair+"bouncy or dangly bits"+clothing are ALL a bunch of meshes, with geometry and textures to download and allocate memory for, and everyone who renders that person on their screen has to download and store all that data, including all the components of it that are "hidden"
You are quite correct to call out hair as one of the most wasteful applications of "multiple hidden options" but that is only a difference in degree, not nature.
I am truly not trying to be judgemental here but isn't "everybody else does it inefficiently so I can get away with it too" just about the worst reason for making a particular design decision? Aren't you proud of your work and want to make it the best you can make? Do you really want to be one of the people whose customers get a really nasty surprise when/if project ARCTAN hits the grid and complexity gets rationalized?
Hello Da5id,
let me please try to elaborate a bit more. As first mentioned by Wulfie, hidden textures will always get rendered, no doubt about that and no argument either... hence my...
8 hours ago, hectic1 said:We can't have it all, I wish we could. It's always a trade-off, but it's good to have more options so anyone can choose what works best for them each time (pros vs cons).
a few posts above. We all agree on that.
Regarding the "apples and oranges", calculating the rendering-cost of any mesh wearable does not affect the calculated rendering-cost of any other worn mesh wearable. Yes they all sum up in the end, but here our point of reference was the clothing set, not the overall sum of all the wearable meshes. Put otherwise, if you start with a mesh body that skyrockets your complexity by itself alone, there is little point in blaming a hidden 4-faces pair of shorts, or a hidden 1 face tank top, and so on. I hope it makes more sense now.
I agree hair is a difference in degree not nature, but in our case the degree is one of they key factors one should account before deciding whether they should go with one option or another.
For one, a fully worn set, render-wise will cost exactly the same regardless of its consisting pieces being linked or no. However, the unlinked one will carry at least as many more scripts as the consisting parts minus 1 (the texture changer slave script), and if the outfit is also interactive (any kind of interactive... undress me, water interactive, or whatever) chances are it will carry twice as much scripts in it.
So what is more important in this case? Frankly I am not to decide that. I believe it should be the customers' decision, and I assume the criteria would be quite different when the customer is say a stripper, compared to a home loner, a dj, and so on.
So texture rendering is one factor, script count is another one, attaching slots is yet another one, for some ppl items count in inventory plays a role too, and one's habbits/whereabouts/style of virtual life are some extra factors too. And there is more, computer rig, quality of internet connection come in mind.
Honestly I don't see what's the harm of having just another option in mind. We have like a gazillion options already. Most of which is out of our control anyway (I mean even if we walk around in system avatars with system clothes, we'll still have a hard time in a sim full of say moving trees, animesh creatures, and a gazillion little scripted 1024x1024 textured petty items all over the place... or even in a crowded club with 40 avatars crowded in and around a 5x5 dancing floor, having no control on the baggage they carry).
-
Yes sweat was a bad example Wulfie, see above. But I am not sure its the same with makeup, lipstick, eye shadows and such, cause those need to be aligned more precisely on their proper places. If BOM forces everyone to use the same UV maps then all good I guess, if not then they will probably show misplaced on different heads.
-
Oh you are right about that Alysa, my bad (actually with BOM you can bake up to 64 layers into 1). Sweat was a bad example, but how about eye shadows? makeup? lipsticks?
PS. My looks, yes they are quite important to me, I hope I don't have to justify why LOL
-
12 minutes ago, Wulfie Reanimator said:
I would love to rewrite those scripts so that they fit into a single script. Obviously I don't know the specifics yet, but I'm very curious. You can PM me if you'd like that.
Undressing should be just an alpha swap and an integer to keep track of the current state... It's very small and simple code on top of texture changes.
I understand it's a bit different when creators buy ready-made scripts without knowing LSL, but that's why I try to offer as much help as I can wherever I can. And there should still always be a way to delete all scripts from an object, even if it meant adding one more script into the dang thing.
In a primitive form yes, that's an undress me script. Mine is on steroids tho (well will be when released) *chuckles*
-
54 minutes ago, Bitsy Buccaneer said:
It sounds like you've decided that your own efficiency is more important than the amount of data needed to be downloaded. If it were just you, maybe ok. It isn't, what with multiple-pieced, multiple-faced onion skin bodies with six feet instead of two, multiple "style" hairs, and so on. If this thing of wearing 2 or 3 complete outfits in order to mix and match were to catch on, the bloat would be even greater.
There are real costs to the grid.
Umm.... I see uncalled teeth, makes me wonder whether I should use mine too in my reply. I choose not to, this time.
I shared an alternative that works for me and I explicitly presented it as such, in a specific context too, namely: clothing!
You made it sound like I tried to enforce it, and you generalized.
For starters I don't see what multi-pieced multi-face onion skin bodies have anything to do with mesh clothing. Your body will be rendered regardless of what other mesh you are wearing or not. Apples and oranges.
Then, I only talked about clothing, not hair. Btw linked multi-style hair is already used by many brands for quite a while, so seems like it's not just me who decided etc etc. Nevertheless, again hair and clothing is NOT the same thing. On average, the linked pieces and/or used faces of hair are multiple times more than any clothing or even a dozen of clothing pieces. I never suggested anything about hair, i didn't even talk about hair.
Everything costs to the grid, there is no such thing as a free meal. Moreover, not everyone has the same needs nor evaluate their needs with the same criteria (textures vs scripts, outfits vs separates, the list is endless really). Hence, imo, the more the options the better.
-
Texture/Color/Style/Gloss/Glow changer (that's what I called the HUD above) is usually a separate script from Undress Me.
Some reasons from the top of my head: maybe they were purchased separately, or maybe one was written long time ago and when need raised for the 2nd one it was not possible or was much easier to write a new one than refactoring and merging them, especially when you work on deadlines.
In my case the main reason is that each of them is pretty involved, so they don't fit both in 64k
Sorry, I should have been more specific.
-
I'm sparing the quote splitting for now lol Thank you for explaining to me Wulfie, i'll use it when is mnore needed.. seems like we are the only ones taking now! ♥
Oh I think the confusion came because I used as an example an Undress Me set of clothing... so for each clothing piece i counted 1 script for the hud-slave, and 1 script for the undress-me functionality... I didn't take into account the hud-master script at all.
For the bodies, yeah neither option is perfect. Consider also that often I have to deal with 14 or more body sizes, add to that their demos, and sometimes different versions within each body. I do name my stuff consistently, but even if one doesn't, the script can look just for the body name (instead of the the whole item name). For example, unpack only those items that have "freya" or "isis" or "venus" (or any other alternatives one may use) would work for Belleza related items only, etc.
Anyway, tbh I don't think it's that important, since ppl can always delete all the bodies they don't want after unpacking anyway (else I would had already used such a script lol)
-
15 minutes ago, Wulfie Reanimator said:
Okay, I think we're mixing the context a little bit.
Yes, if you only have literally one surface for body and head, you can't add a material specifically for the lips if you already have some other head material (without replacing it).
No, there isn't anything particularly wrong with materials and BOM. In that post, I was debunking a statement that "you can't use materials with BOM."
No worries, sometimes typed communication can be confusing indeed.
I think the "you can't use materials with BOM" thing is mostly spread due to the fact the the Lab stated BOM does not support materials.. And frankly what you showed is quite helpful, I for one didn't know it was working, tho I still have no idea why it does, since BOM isn't supposed to support materials. Nevertheless, it does seem quite crippled compared t what we are used to right now.
-
Someone has to tech me how I can split quotes so i can reply to individual parts (I don't seem to find an option to switch the forum editor into bbcode view).
Say you have a jacket, a top and a skirt, all controlled by the same HUD. Unless you link them all together (which is what I am saying right from the start) each of the clothing pieces should contain a slave script which will communicate with the master script (in the actual hud). Unless there is any other way I am not aware of.
Awe, that's what you meant it is simple. Yes it is, but also time consuming. An arguably better option would be for the unpacker to offer options for unpacking individual bodies only and it would work the same on MP and in-world, and some creators do it. It is in my to-do list since a long time, but I'm not sure it is worth the trouble.
-
28 minutes ago, Wulfie Reanimator said:
What I've shown in the post that I linked is exactly what we have right now with mesh bodies without BOM.
I've already went through this in the other thread and I made arguments for both sides of the conversation. Onion layers should not be used for clothing, besides for one extra layer that is not form-fitting and covers gaps like butt and clevage, like an "undersuit." You can't currently have more than one set of materials for your skin, just as is the case with BOM. There's no downgrade.
Materials are just as static as the baked avatar textures. There's absolutely no difference between them, besides how they are interpreted for lighting, and it's the lighting and shading that's "real-time." You can see that BOM textures themselves are affected by lighting, as you can see shadows and different colors from different sources of light on them, even without materials...
I am not talking about clothing, I am talking about things like tatts, eyelids, lips, etc... and no, what you showed is not what we can do right now. Right now we can make a materials enabled tattoo without affecting anything else on the skin, same for the lips, etc and we can turn them on and off on demand too JUST for those parts only.... with what you showed we would need as many diffuse, normal and spec maps as all the possible permutations for the different states of each individual part. So no, it's not the same at all!
About real-time interaction, I don't really see what your argument is about. I didn't say anything different. Materials are all about real-time interaction with SL's lighting system, and they are static maps yes, but especially made for dictating/faking the run-time "3d" looks when interacting with the lights (skin pores, lips wrinkling, etc).
-
45 minutes ago, Wulfie Reanimator said:
1. Your math seems off. A 3-piece set only needs one HUD, not 3. That's 4 scripts total, not 6. I'm a scripter, I know these things. (And incidentally I tried talking to the Undress Me creator about ways to improve things but I got stonewalled as is typical of all no-mod clothing creators.)
2. The number of inventory items per product doesn't matter. People should package their products with separate folders for each different body. It's extremely simple with Marketplace. If you're a shopaholic with 300K+ inventory items and it's causing you performance problems, that's a whole other problem.
The only legit worry is the number of attachment slots, but since the current trend is to make literally all clothing no-modify, you're not going to be linking sets together to reduce them anyway. That means it must be the creator's choice, which is even worse.
1. I said HUD-slave scripts Wulfie. Also I said pieces that can be worn separately (aka, the traditional way) Each one of them needs a HUD slave-script, so my math is quite good ( btw, I for one am willing to listen to your suggestions, since I'm about to release my own Undress Me line of clothing, with my very own script which includes a few extra twists... btw, there are more than just 1 undress me creators)
2. I am all ears *giggles* (I do hope though it is also extremely simple to do it in-world too)
-
13 hours ago, Wulfie Reanimator said:
Of course, here you go:
Thank you Wulfie, I just had a look at that thread. It's been already pointed out in further replies of that thread that what you showed in the picture is not really what we do have right now. Right now we can control materials on individual parts basis, while what you showed applied the same materials to all parts. Also, with onion layers we can have things like sweat over the skin, etc.
I have no idea if materials as we know them now can even get implemented in BOM, cause materials is all about real-time interaction with SL lighting system (ALM), which is kinda the exact opposite of static bakes.
I hope most body/head creators will settle with hybrid solutions (e.g. provide some extra layers on top of the BOM layer, probably less than they have right now) and that's what they are already doing in my experience. We'll have to wait and see I guess, but right now it does look like a downgrade for our hard-worked looks lol
-
12 hours ago, Mollymews said:
from a ease of scripting pov then yes this would be simpler
a display name, when different from a username, is what the person prefers to be known as. OP script takes this preference into account
Nods! However, ll2Key() besides making the script easier and lighter, it also guarantees the name returned is unique. Combined with the menu buttons limit would decrease even more the (thin) chances of names appearing as being the same inside the menu. Nipticking, but maybe worth noting.
-
11 hours ago, Wulfie Reanimator said:
And the negatives are that the invisible parts are still streamed to your viewer and cached. They might not be visible, but they still affect performance.
Any piece of clothing should either be modifiable (in a perfect world) or at least have the option to remove all scripts.
We can't have it all, I wish we could. It's always a trade-off, but it's good to have more options so anyone can choose what works best for them each time (pros vs cons).
For example, with the "traditional" way, an Undress Me set with say 3 pieces which can also be worn separately, would come with a HUD slave and an Undress me script inside every piece of the set (6 scripts for the set), would occupy 3 attachment slots on the body, and it would ship with 3 x NumberOfSupportedBodySizes items in the inventory (just for the big-3 this means: 3 Maitreya + 3x3 Belleza + 3x2 Slink = 18 items in the inventory). Wearing 2 out of the 3 pieces, would reduce the scripts count to 4, the attachment slots to 2 and the inventory items to 12.
The hideable-pieces alternative would always contain 2 scripts, would always occupy 1 attachment slot on the body, and it would ship with 6 items in the inventory. It's up to the potential buyers to decide if those are more important compared to the always-rendered hidden textures.
Among other things, modifiable clothing would allow everyone to apply their own textures on a clothing mesh they have bought at a multiple-times lower price compared to buying it full-perm or creating it themselves (could also mislead people who inspect the clothing in believing that this crappy/awesome texture was made by the displayed brand).Script removing is something that has puzzled me too (whether I should offer it as an option or not). It is dead simple to put a Remove Scripts button in the HUD, but I decided against it, cause it totally cripples the functionality. and in 2020, clothing can do so much more than just keeping us warm.
-
On 1/11/2020 at 6:00 PM, Wulfie Reanimator said:
You 👏 can 👏 apply 👏 normals 👏 and 👏 speculars 👏 onto 👏 BOM 👏 enabled 👏 mesh.
Don't let anybody tell you otherwise, many people seem to have this misconception.
Also, BOM works just fine with makeup. The SL body UV has a texture for the entire head and BOM can blend partially transparent textures, just like with tattoos.
...
Sorry, but I am not clear about BOM and materials at the same time. I was under the impression that BOM does NOT support materials, and that's the reason I don't see me jumping on the BOM wagon until they add materials support.
Right now we can have materials on pretty much everything, via the appliers (well depending on the mesh body/head brand): skins, makeup, tattoos, etc. It is my understanding that all those are now baked on just 1 layer, the BOM layer, and BOM does not support materials.
So Wulfie, can you please expand a little more on your above post?
-
Hello,
Regarding sets and separates, what works best for me is hud-driven sets with hideable parts, and that's why I put the extra effort to make most of my sets like that. For a top and skirt set example, when you can hide either one is practically the same as wearing the other one as stand-alone (and of course mix and matching it with other clothes too).
There are also several advantages with this:
- You always reserve just 1 attaching point on your body for the said set, no matter how many pieces the set consists of
- You keep less items in your inventory
- No matter which piece you have hidden or shown, there is always just 1 script needed (instead of as many scripts as the count of the consisting pieces)You can still "simulate" traditional 1 inventory item per clothing piece by keeping copies of the set, with only the desired piece visible, but frankly this defeats all the said pros lol It may take a little used to, but it really works and imo it is worth it too.
-
1
-
-
Thank you Wulfie!
-
Hello everybody, just my 2 cents...
In my experience both as a merchant and as a consumer, anyone can find pretty much anything in SL these days, and since a long time really.
A search on Marketplace for example, more often than not, can get you to what you are looking for in less than 10-15 minutes. Especially if a) you set the "Show Results" filter to 96 instead of the default 20, and b) you use AND and OR among your search keywords. Seriously, there is NO lack of any style at all! Usually there are way more styles than we ever thought existed at all lol
I don't mean to sound harsh, but if someone REALLY has trouble finding something as common as non-revealing clothing, then i think the first thing to do is asking themselves what they're doing wrong (before blaming it on the merchants, the Lab, or anyone else *giggles*).
As for quality/skin poking/piece matching/etc issues, the vast majority of merchants offer demos. If you buy without try, then it's on you again,. We do try our clothing before buying them in RL, right? And not every new buy plays well with every older piece of clothing we have in our closet, or we'll buy in the future either.
Regarding styles, and "tagging" clothing and people etc, I can only speak for myself but I can make a point I guess. There are times I feel like being totally s-l-u-t-t-y, and there are times I feel like being the most elegant in the room, and there are times I feel like being the most classy one in the ballroom, and there are times I feel like being seducing someone in darn revealing clothes or lingerie, and there are times I feel like just throwing on a hair tie, tee, jeans, & sneakers, and there are times I feel like being someone noone notices (well, that one not really hahahah) and so on. So, what am I really? A dirty ho, a ballroom diva, a tired wife, a sensual mistress? Is there just 1 shop or even just a dozen shops I should only buy from? And I haven't event touched the hair, shoes, makeup topics lol, Nor Roleplaying, this is SL after all.
Anyhoo, what I am trying to say I guess is that imo most people have more than 1 or 2 styles anyway, and the norm when shopping is to look for what you are after regardless of what other product the store sells (it could be selling dildos too for crying outloud, who cares?... I just have to have that dress they also sell or I am after).
Okeis now it seems more like 20 dollars than just 2 cents LMAO (sorry for the... essay *laughs*)
-
1
-
1
-
-
On 6/10/2018 at 5:56 PM, Madelaine McMasters said:
...
It's a shame that LSL doesn't have conditional interpretation, allowing unwanted debug code to be ignored. "if(iDebug)" doesn't take much time to execute, but it does take time and the debug code takes script memory. In the world where I worked, there were "preprocessor" variables that controlled how the compiler handled various statements. If I'd made "iDebug" a preprocessor variable rather than a program variable and set it to FALSE, the compiler would ignore the block and no code would be generated for it at all. If "iDebug" were TRUE then the code would be generated and no test for its value was necessary. It's no longer a matter of deciding whether to execute debug statements as the program runs, they're either in the program or they aren't.
...
Half of a year delayed reply, but what the heck! Not sure since when, but Firestorm does come with a pre-processor option, which works very similarly to the C/C++ pre-processor. ☺♥
-
1
-
-
Wouldn't be much simpler to just use llKey2Name() instead of llGetDsiplayName()? It returns the legacy name of the avatar which I think it's guaranteed to consist of ascii letters only (double check on that please).
-
Thank you all for your input! I'll prolly switch to the one-liner from now on ♥
14 hours ago, Wulfie Reanimator said:They're not SL specific.
- jump and @label are just C's goto
- ~ is One's Complement (bitwise operator, also from C)
- - (minus sign) just simply means "negative of" as in "-2" is "negative of 2"
...
Thank you for the detailed answer! Actually I'm pretty familiar with C. Sorry if i made it sound otherwise, but by "SL ~- specific hacks" I meant I am not sure I should restrict the code of this function on machine architecture specifics, cause I am also using it in OpenSim (and frankly I'll have to test the one-liner there too before I adopt it). In SL I often use bit operators too, but mostly for compacting booleans to integer bits (besides the mem gain, it's quite handy for permanent storage/retrieval of "settings", say on a child prim's description, name, or whatever).
You are right about the one-liner's big speed gain, I should have probably thought of that *giggles*. The thing is I have no idea about the internal implementation overhead of lists versus strings, and their corresponding functions, so it's usually not obvious to me which one is better to use in different use-cases. Btw, do we have access to the internal implementation code of LSL? Lists and strings for starters would be nice. I was always wondering for example, does llStringLength() actually parses the whole string or is the length saved say in an overhead byte/word in the front for rapid access? Same for llGetListLength(), etc, etc.
12 hours ago, KT Kingsley said:Regarding the 512 byte memory difference, I understand that mono LSL aligns user functions on 512 byte boundaries, so inline code tends to use less memory than a function, at least up to the point where the inline code is repeated often enough to overtake the function's memory usage. Which way to go depends on which you value more: your sanity or your script's memory usage.
So true, and Firestorm's pre-processor macros support is a God sent for keeping most of your sanity when inlining lol. However, finding the sweet-spot after which a heavily used macro should be converted to a function is pretty much a "trial-and-error" thing, at least in my experience so far (very recently I saved more than 5K of script memory by converting a couple of macros to regular functions, but it took me time to figure out that "sweet spot" lol).
17 hours ago, Fenix Eldritch said:I notice that your function uses a loop, but Haravikk's function does not. That might give their code an edge over yours, since you have to spend additional resources looping through the string to break it up. Haravikk's code on the other hand lets llDumpList2String do the dirty work.
But to truly know which is better, you should do additional tests, with different sample inputs and look at the averages. You can find a speed tester on the wiki here: http://wiki.secondlife.com/wiki/LSL_Script_Efficiency#How_Fast_Does_That_Code_Run
Very nice links, thank you very much!
-
Hello,
I was using my own string_replace() function which I wrote using strictly string functions: https://prnt.sc/qqc2pp
Today I run onto this one-liner which is using lists instead: http://wiki.secondlife.com/wiki/Combined_Library#Replace (I didn't bother "deciphering" the 2nd implementation with all those ~- SL specific hacks lol)
I was wondering if I have anything significant to gain if I start using that one-liner instead of my function. Seems like that the one-liner produces smaller bytecode by 512 bytes, tho I can't be sure cause I checked with llGetUsedMemory() and Mono is supposed to allocate needed memory in 512 chunks, but my query is more about any significant run-time benefits regarding memory and/or speed.
Thanks!
-
2 hours ago, Rolig Loon said:
No. Not only is the delay unnecessary, it may mess up other things. Unless you ever have a real need for using llSleep -- and there are plenty of good reasons to use it -- avoid it. llSleep does exactly what it says. It puts your entire script into sensory deprivation, so that it cannot respond to other triggers that you may want to be aware of.
Great! Million thanks once again! ♥
-
1 hour ago, animats said:
There's something called PrimSwim used by some swim HUDs which handles "are you in the water" for swim HUDs. Can you use that, and be compatible with existing swim HUDs?
I think you mean the Waterworks prim-water script, also creator of the following HUD (among other things):
In the description it says a lite version of that script is included with the HUD. I had searched for it (PrimSwim) before I post in the forum, couldn't find it. Probably it is not free, and as far as i know, not even available separately. Even if it was, I would need to check the code for its listening channel and its expected messages when ppl go in and out of their prim.
Or I could contact Waterworks, asking for that info. However, I had a look at the 1st review of the above mentioned HUD, dated in October 2018 saying that the hUD gives a ""Attachments cannot use llVolumeDetect" (hinting that they try to use llDetectVolume() inside the HUD script, which couldn't work anyway according to the Wiki). That, combined with the 2nd review which is a good one but dated back in 2017, made me think that probably that HUD and the PrimSwim script coming with it is probably either outdated or abandoned (and using llDetectVolume() too for detecting).
That's when I started looking for other alternatives, hopefully most recent ones. Plus I much prefer the HUDs to be free, since I'll be giving my prim-water free too.
I have already made my prim-water compatible with 2 free Swim HUDs (namely, AT-Swimmer and Thor's OAK HUD) and I'm totally happy with it. As i said, my main concern is that my prim-water works with my very own line of WetSense clothing (not released yet) and it seems to work fine so far. The free swim ability will be an extra bonus for pool owners (creators) who will be willing to use my prim-water.
PS. About my last question? Does anyone know? Should i insert a short delay between consecutive calls to llRegionSayto() or I'm fine w/o any delay between each call?
Facebook
Instagram
Twitter
YouTube
Flickr
What is the benefit of BoM exactly, besides salvaging old skins?
in Fashion
Posted · Edited by hectic1
Hello everybody,
I was waiting to see how Maiterya will implement BOM, before I seriously test it. They did, and in my opinion they offer the most versatile and effective way to optionally mix BOM with layers.
They got rid off the traditional tatt, underwear and clothing layers, but they do offer them as separate wearables, which is brilliant. All is handled from within the same HUD. Want to use an applier? sure, put on manually the destination layer and apply what you want on it. You don't want layers? Sure, take them off and be plain BOM... brilliant! Thankfully, they also have a full-body materials layer, so you can apply them on the body (they do include 2 materials by default in the HUD, plus no materials). You want system clothing (tatts, underwear) with materials specific made for them ? Sure, put on the clothing (tatt, underwear) layer and apply them there (those come as appliers -old school system layers (BOM) can't have materials).
I tested pretty much all mainstream mesh female bodies (and a few male ones too), and from what I've gathered Maitreya is the only one with that brilliant implementation. Most of the other bodies I tested, they always carry all layers on them (even when putting them in BOM mode), while very few offer 2 separate bodies: BOM only, and layered only.
I'm now all BOM as far as my body is concerned, though I can't quickly turn on and off tatts/makeup from HUD when photoshooting (now I need to hunt them into Worn tab to take them off and hunt them into Inventory to put them back on). Understandable, we can't have it all (darn it lol)
Regarding mesh heads, I kept my non-BOM Catwa mainly for 2 reasons: a) my currently favorite skin doesn't come with a system layer for the head and it won't be updated (I asked) and b) Catwa's BOM Relay HUD doesn't reduce the number of worn layers, so not much gain in avatar complexity (in their update they just converted their BOM relay HUD into a button in their Master HUD). I didn't have the chance to test other heads, and frankly I won't for a while, till I find time again.
For now I am happy with BOM body and non-BOM head.