vometia

I figured it was probably a DoS attack; and coincidentally (or not) today I'm getting a lot of Cloudflare "checking you aren't trying a DoS attack" pages, which is annoying. But less annoying than the site being down. And people who do DoS attacks.

It certainly gave me quite a headache in the process! I'm afraid I never did discover how it's done in spite of looking at a number of different files; though I admit I'm not an expert at hunting down elusive data, especially when I don't know exactly what I'm looking for. What I did find is that it isn't the value that was changed from 0 to 8, unless I was doing something wrong: that just comprised part of the file number it loads for a specific model and if an invalid number is given (i.e. file doesn't exist) it won't swap out the body part which gives the illusion that it does what we're trying to accomplish. My conclusion was that it's (probably) not specified in any of the files I was looking at, be they ITL, AMR, ATR etc and nor is it done by the MOD (the model/mesh) file itself: no amount of trying to fiddle about with any of them produced the results I was looking for. So it's either specified elsewhere that we don't know about or it's some complex calculation based on more than one of the previous things. To the best of my knowledge, nobody else has accomplished this either; or at least I wasn't able to find even one example of it. There are some mods doing the rounds that seem to have accomplished this but what they actually do is a complete retex of another item that already has the required properties. This may or may not be a useful solution, depending; for me I think the purist in me wanted to know how to accomplish it, as well as not wanting to "sacrifice" other piece of armour or clothing.

Apologies for the rather leggy format, a combination of IP.Board's buggy editor and Nexus' insistence on the bloody awful Re:CAPTCHA which seems to be broken again is making it really hard to post.

It's apparent nobody else is (currently) looking at any of this, but for posterity... :D I'm still going back to this now and again because at this point I just kinda want to know the solution and it irks me that I haven't found it. What I have discovered so far: What doesn't control the body-part map: bbs_rpg.arc/etc/items/itemlist.itl (see note 1) bbs_rpg.arc/model/pl/parts/[fm]_parts.amr (see note 2) bbs_rpg.arc/model/pl/parts/m_parts.atr (see note 2) eq/[aw]_*/[fm]/[fm]_[aw]_<part><no>.arc/model/pl/*/*/*.mod (see notes 2 & 3)...and therefore what doesn't work:Trying to respecify the model numbers listed in m_parts.atr (there is no corresponding f_parts.atr), including trying to forcibly add the underlying body parts. Copying and renaming the *.mod and *.mrl files from a different model: the clothing/armour displays correctly but body parts to not activate or deactivate accordingly. Guessing that it may be encoded into the file number: changing the number (which obviously includes changing the m_parts.atr file and even *.amr) makes no difference.What works correctly: Changing the equipment file number in both itemlist.itl and NPCs' *.edp file (see note 4) Notes: Although I have no idea what most of the stuff in this file means, changing the file number simply swaps in the relevant models and activates or deactivates the relevant parts as necessary. No further changes are needed. This contains a number of fairly opaque (to me) binary values. I have no idea what any of them mean. The *.mod files contain strings named [AB]XfBAN__E_00_m010_ followed by a (presumably decimal) number. I wonder if these correspond in some way to the values seen in *.amr and/or *.atr. It looks tempting but I'm not certain and it's very hard to see definite patterns emerging but it seems a tempting idea. If this is how it works, it might explain why I've seen no patterns as they could be worked out on a file-by-file basis; though that would make working out the co-existence of armour parts exceedingly complex. I mean more complex, e.g. the Gauntlets of Shadow which make the sleeves of torso armour disappear, and the torso armour in turn may make chest clothing's sleeves disappear, and the chest clothing may or may not make the character's arms and/or hands disappear... etc. *.edp defines various stuff about the NPC's appearance, which is described elsewhere. In terms of what they have equipped, they use either an outfit ID, which is most of them and I have absolutely no idea where this is defined, or individual equipment parts comprising the file number and slot number it occupies (remember that equipment slot IDs are evidently not the same as body part IDs: it seems there are many more of the latter). Most NPCs use the outfit number, and others have documented how this can be changed which swaps everything they are wearing. The few NPCs have individual equipment IDs that can be similarly altered and doing so makes them behave correctly.Conclusions I still have no idea how and where this is controlled. It's either using a calculation using the data that's right in front of me that I'm just not seeing. File formats AMR files: These contain a list of *.mod/*.mrl files, one or more of which is included with each equipment file. a header comprising four int32s: The first is set to 0x00726d61 ('amr\0'), the third is the number of records, and I've no idea about the second and fourth. Variable length and comprising two int32s followed by a zero-terminated string. The first int32 contains a unique model number for each individual *.mod file starting from 0. They are not contiguous i.e. the entry for a model can't be inferred from its position in the list. Some entries are invalid (presumably deleted at some point) in which case this is set to -1 and skipped. I have no idea what the second specifies. It's usually set to 0 though a few have it set to 1. The string defines the path to the model (minus the extension; it expects to find both *.mod and *.mrl; the mrl defines the paths to the textures independently). As the variable-length thing is on a byte-by-byte basis the int32 values are often not word-aligned, something to be aware of if searching a hexdump. Some records have no strings but (obviously) still a null terminator. After the records there're two (I think) int32s whose purpose is unknown and a chunk of data whose byte count seems to correspond to the number of records if we subtract the number that were skipped (e.g. set to -1). Might this be our body part data? Dunno, can't see any obvious patterns emerging.ATR files: These link a list of model numbers to the equipment file number. They comprise the following: A header comprising four int32 values which seem to be in the same arrangement as the AMR file, i.e. the first is set to 0x00727461 ('atr\0'), the third is the record count and, again, the 2nd and fourth are unknown. A series of variable-length records comprising three int32s and "an array". The first int32 contains the equipment file number (effectively a short, I think) with the high byte set to the equipment slot number, e.g. 1 for chest clothing, 2 for leg clothing, 3 for helmet and so on. This corresponds to the files found in nativepc/rom/eq with the equipment slot number defining the directory and file prefix and the file number providing the numeric component. The second and third values are unknowns. The first contains an integer which is typically a multiple of 10, e.g. 580, 700, 800 but I have no idea what it means. Size? Weight? Probably not value as that's what itemlist.itl does. The second contains a smaller number; it's tempting to assume this is something to do with body parts but I can't see a pattern emerging. The "array" comprises an int32 specifying the number of elements and that number of int32s which specify which AMR entries are included. Nomenclature:"Model number": the ID number of the *.mod file specified in the AMR list, e.g. a pair of sleeves. "Equipment number": the file number of an equipment definition, i.e. the numeric part of the *.arc in .../rom/eq and what was described in being in bytes 60/61 (I'm counting from 0; bytes 61&62 if counting from 1 as the attached image does) of the itemlist.itl file. This contains one or more model numbers defined in AMR, e.g. an item of chest clothing might contain the pair of sleeves mentioned and the waist part(s) such as belt etc in addition to the chest part itself. "Item ID": the internal ID number of any given piece of equipment found in the likes of a save file and in bytes 56/57 of itemlist.itl

I've been faffing about with this periodically and got precisely nowhere yet! I guess there's a reason there isn't a huge amount of armour/clothing replacements out there. AFAICT there's nothing in the itemlist.itl file that specifies which slots are to be occupied and optionally occluded; the only thing that changing byte 62 will do is make it look for a different *.arc to load and if it can't find it, you get the body part instead. Maybe: that's what happens for chest armour but I didn't test it for things that can straddle (at least) two body parts such as gloves, boots, helmet etc. I spent probably too much time trying to figure out exactly how the pathnames in the *.arc files are referenced and that seems to be courtesy of bbs_rpg/model/pl/parts/*_parts.amr; the format is a little confusing, I guess it's more of a data stream or hierarchical database than a bunch of defined record types, a bit like e.g. NIFs, which I guess isn't that surprising. Anyway, it seems to be a short int containing the file's reference number followed by a short zero; the item number can be missing in which case the following strings are some sort of array or list but I'm not clear how they're referenced, maybe just by whichever one it finds. Following that is a (presumably) long int which contains either 0 or 1; no idea what that does. And then a null-terminated string which is the path of the model it wants minus its extension. These file numbers are referenced by either the *.atr files; confusingly, it seems there isn't a f_parts.atr, just an m_parts.atr. Anyway, this is what links the stuff you see in the *.arc files with the pathname, and contains the following: int16 - arc number (e.g. 5500, Madeleine's outfit) int16 - item type, e.g.0x400 body armour, 0x200 leggings, 0x500 boots etc. int32 (maybe: I'm guessing as the high bytes of all the following numbers are zero) - no idea int32 - no idea, again int32 - number of models required int32 (array defined by previous number) - pathnames referenced in *.amr I have tested this and have persuaded it to load up additional models in a given outfit even for female characters so it definitely seems to do both. However, what it does not do is specify where they're to be loaded and more specifically whether they're replacers or overlays. It seems that is done elsewhere. I suppose one could conceivably add the body part to the list of models to load, I've no idea if it would work whether the skin tone would be rendered correctly and if the textures would clash with each other. Maybe I'll try at some point if I can find the patience! There seems to be other stuff involved because just as an experiment I tried to see what would happen if I tried to change the arc number in itemlist.itl and m_parts.atr; first attempt at hex editing I made a typo and put the wrong value in itemlist so nothing loaded and I got a nude lack-of-outfit instead, but on correcting the typo it moaned that it couldn't find the constituent files, which was confusing. Anyway, just documenting my findings to date as well as "and this doesn't work".

Possibly a bit late in the day, but it seems that bytes 60 and 61 are the equipment ID and, confusingly at first glance, 61 and 62 comprise some sort of indicator as to which body parts are disabled or not (presumably a straightforward bitmask). I had a hunch about this when I was poking around in some other files and could find the values I was looking for only if I treated it as a 12-bit value, i.e. 1.5 bytes. I may of course be totally wrong but it appears that bits 0-3 of byte 61 are the high bits of the item ID which also consists of byte 60 (by which I mean the ID referenced by DDDA.sav.xml's mItemNo, not the one in the *.arc filename) and bits 7-4 usually seem to be set to 0xe. I may be wrong about the high bits of 61 belonging to the body-part mask but it seems that the ID number if taken as a 16-bit value usually has 0xe000 ORed with it, that data seemingly being used for some purpose that is nothing to do with the ID no. Edit: sorry, this is nonsense. Well, half of it is: that the item ID is a ~12-bit number appears to be correct but my concentration was AFK and got the wrong bytes, which should be 56/57 (counting from 0, that is).

A rather belated reply, but I'd much rather see this gone altogether: reCaptcha causes me so many problems and my heart just sinks as soon as I see the "select all street-signs" one pop up as I know I'll be in the never ending cycle of doing one after another, and it either failing or wanting more verification, and gets slower and slower and Google eventually blocks my (static) IP. I know it's not just me (though I do have the additional disadvantage that there is no "absolute" answer a lot of the time, it's based on a consensus of how people tend to think; only I'm autistic, and kinda the definition is that I don't think the same way as most people) and it doesn't seem to be anything I'm blocking either since I can sign into Google services just fine, which miraculously makes the Captcha much less onerous: but I don't really want to do that every time for all sorts of reasons. And given that I'm a lifetime member, I'd hope my blocking of this and that for security reasons isn't an issue anyway. Although I agree that more security is generally good, Google isn't really the place to provide it: not just the frequently problems with reCaptcha itself, nor the privacy problems, but as a provider, Google is so indifferent to people having problems with its stuff that it can't even be bothered to shrug.

I dunno, maybe it's because of the tech companies I worked for over the years. Some of the random acts of management were... "curious", and I remember to this day the interesting conversation I overheard from an aimless gaggle of managers who were remarking that their 1337 management skillz were so awesome that they didn't actually require any knowledge of the company or its products. DEC went out of business a couple of years later; well okay, it was bought be Compaq, but it was a fairly ignominious end for the former IT empire. I think it's easy to be too paranoid about a company's motivations, even with the likes of EA and its ilk, but one can never go wrong when expecting curious and random decisions to spew forth from executives.

I am concerned about the same thing and fear that you may be correct. Although attempts by industry types to go down the proprietary route is seldom successful, it doesn't seem to put them off. I'm particularly concerned as Bethsoft seem to be repeatedly upping the stakes with mod-prevention with FO4, and I worry that they may not figure out it's as bad an idea as when anyone else does it until they find out the hard way.

Thanks. :)

Spent quite a lot of time experimenting with that but I was unable to get my mesh to show up in game, whatever Nifskope thought about it. If anyone knows of a step-by-step tutorial (preferably an idiot's guide that doesn't assume anything!)...

Apparently there was a decision by Bethesda's sales team that the worldwide Steam release would be delayed to coincide with Sony's PS3 release date. I guess I don't really need to add any expletives.

They do have a rather annoying habit of adding a bunch of fake "received" headers to either throw you off track or make the message look more legitimate than it actually is. I'm still amazed that internet mail hasn't been superseded by something better: it's years since I looked at its innards and thought "that can't be right!" when I realised how insecure it is (this was in the years BS: "Before Spam"! Little did I know...) But I suppose as long as the corporates keep trying to punt their own proprietary services as The Answer we'll be stuck with it...

How slightly irritating: I was wondering why I was starting to get spam delivered to my Nexus address. Thanks for keeping on top of it though, guys, and especially for keeping us informed about what's been happening. And thoroughly bad vibes to the script-kiddie for being an unpleasant nuisance.

All I can think of is that "The King" had a taste for them, but I'm guessing that the significance should be a bit more significant!