Tannin

The compiler is probably a "universal" binary, that is: the exe actually code for 32bit and 64bit and runs whichever matches the system. When running the creation kit via MO, the compiler should run but it will not see the vfs. It should however see the mod directory that contains the script to be compiled! This means that it should compile scripts just fine as long as the script doesn't depend on anything in a different mod. I couldn't reproduce the crash you are seeing either.

new beta that should fix the priority 0 problem: https://sourceforge.net/projects/modorganizer/files/ModOrganizer-1.2.3.exe/download https://sourceforge.net/projects/modorganizer/files/ModOrganizer_v1.2.3.7z/download Please let me know of any remaining issues (through the issue tracker plx)

Custom categories are stored in the file categories.dat.

I just uploaded MO 1.2.2 which supports the feature TheBloke proposed. Right now it's only on sourceforge because I'd like to hear your opinions first:Installer: https://sourceforge.net/projects/modorganizer/files/ModOrganizer-1.2.2.exe/downloadArchive: https://sourceforge.net/projects/modorganizer/files/ModOrganizer_v1.2.2.7z/downloadPlease note that the tutorial is a bit broken currently, but you don't need that, right? ;)

That is one feasible solution, it will treat all BSAs like with other mod managers. If you go this route, make sure you keep all archives unchecked (except the grayed out ones) otherwise strange things might happen (see page 10).What we're discussing here is MOs bsa management that simplifies that load order to:1. loose files and bsasThis is what is a bit broken in connection with the unofficial patches. If you don't use it, you're not affected. MO already knows if an esp is a fake esm, but that, to my knowledge, isn't the cause of the issue, a "real" esm could lead to the same issue, no? There is. The game engine does use the file name to represent the plugin-BSA relationship: aaa.es[pm] exists -> load aaa.bsaNot sure if skyrim.esm is special because it's official or if the rule actually is: aaa.es[pm] exists -> load aaa*.bsa but there is a definitive connection based on filename. Only if MO determined the relationship different than the engine, but since the engine itself works based on the filename, this is not an issue. humm, tough cookies, but this is a trade-off:MO never made promises to handle files in data in a predictable way.MO-installed (and managed) BSAs have always overwritten loose files in data, the only difference now is that MO can pull esp+bsa pairs from the "data swamp" so they can be managed properly. This should work for all steam workshop-installed mods, which is a proper bonus imho.NMM installed mods can already be imported through a plugin so I'm not too concerned with mods installed through nmm parallel to MO.This means the only remaining issue is with mods installed outside MO through wrye bash or manually that are loose files but only if the assets are conflicted and if the asset order will only resolve correctly if loose files have the same priority as bsa mods.Honestly I find the use-case that you want to install a mod from steam workshop because it only exists there a lot more reasonable. If someone is using two means of installing mods in parallel he's asking for trouble and shouldn't be too surprised if he gets it.OTOH we could just make it optional and call it a day. ;)

Well, MO relies on Windows to let it know when the mouse hovers over a control. For performance reasons hover events are not sent for all controls but only those marked with a flag. I assume the windows theme you use ignores that flag and doesn't emit the hover event at all. I'm afraid there is little I can do on my end without changing the behaviour of the dialog entirely (as in: not react to move-over event but on click or something)

zlib: https://www.uesp.net/wiki/Tes4Mod:BSA_File_Format#Compressed_File_block This has been well known for ages, how else do you think people are able to extract them? The whole file format is known and documented, same goes for almost all other file types used by that engine. Both update.bsa and Skyrim - Misc.bsa are zlib compressed, there is no lzma data or header there. Binwalk is wrong.

Luck has nothing to do with it, there has to be something unusual about your system that keeps the hover effect from working and we really can't know what it is. Do you use a modified theme for windows? Or some software that might interfere with mouse behaviour? Or an "unusual" pointing device like a wacom tablet? Have you modified the MO stylesheet? More general questions: What version of windows do you use and could you please list at least one mod where you're missing the effect?

I know what lzma is and I know that MO can extract them, I wrote the code. ;) But on BSAs only zlib is supported. Please post the name of any one bsa that is supposed to be lzma compressed. I'm fairly certain binwalk is wrong. Please also note that while BSAs use zlib compression they are not zip files! They don't have any signature other than BSA.

@fireundubh: whaaaat? To my knowledge BSAs only support zlib compression. Do you have a link to a bsa that uses lzma compression? MO wouldn't be able to decompress that.

It's not an error message, is an information (light bulb). Those messages are primarily there to give an error messages context and to let you know things are happening (i.e. in long-running operations) but if MO wants you to react to something there will be an exclamation mark and/or red. ;) You know, signal colors: blue/white says: all is good but just so you know... Yellow say: this is something you might want to look into red says: you HAVE to do something about this

I think I'll go with TheBlokes proposal (the original one, see below) for now. It works and is easier to implement than my own, which means I will have a working solution quicker. My own proposal should still work and I might implement it in a future major update. This gives us more time to consider the implications. I'm still opposed to the idea of treating the unofficial patches special because while it's true that it's unlikely there will be more, there might be further mods from other authors that require similar treatment. Any solution should be as generic as possible, at least in the core program, I have fewer concerns with less genericity in plugins though: What we could do is provide a plugin that checks for "essential mods" and guides the user through the installation, including setup of the right priority. Or fully automates the process. There is only one problem here: Nexus doesn't want tools to directly download from their service. They are partially financed through ads after all. To get the most out of such a plugin it would be ideal if we had an alternate download location for the mods. Also it would be awesome if someone other than me would write the plugin. Not only to save me time but also so we can spread knowledge about the MO plugin interface a bit. One more question: Technically it would be easy to discover all esps (plus associated bsas) in the data directory and display them in MO as "special" mods. This would not only make vanilla skyrim + dlcs show up but also other mods installed outside MO, i.e. mods installed through steam workshop. What do you guys think: Is this a good idea? Unfortunately it would not be possible to discover loose files associated with the foreign-installed esps, nor would I be able to figure out meta information about those mods (i.e. version, nexus id)

Sorry mates, can't answer everything now.@TheBloke: I understood your proposal. Basically the "mods" Skyrim, Dawnguard, Hearthfire, Dragonborn wouldn't physically contain the esp+bsa but they would represent the files in the data directory.I like this proposal, it lets us fixes the problem at hand with manageable changes to MO, the sole reason I haven't agreed to go this route is that it isn't as automatic as it could be. Basically you would install mods as usual and the PMOP warning is guaranteed to show up for the unofficial patches and the game will only work perfectly if the user reads and follows the specified suggestions therein.Unfortunately in the past people have advised users to ignore the PMOP warning and thanks to how the internet works this can not be undone. We will always have users stumble over those suggestions and go "but people have told me to ignore the warning"A question to the informed STEP staff: The step guide currently suggests to prefer loose file versions of mods and unpack the reminaing BSA.What happens if a user installs STEP with NMM and ignores the suggestion, that is: he prefers BSA versions and doesn't unpack?Will his game break, exhibit glitches or are the differences cosmetic in nature?Say we did a compromise of my last suggestion: MO by default activates auto-sorting for mods containing bsas but not for loose-file mods (You could of course always toggle it)In this case, by default asset ordering in MO would work almost exactly like in NMM (except that BSAs would still be able to override loose files if their priority is higher)Would that be feasible for step? The advise could still be to unpack specific BSAs (where step knows a better order than the plugin-order) and auto-sorting wouldn't affect the mod.Or you could tell users that - instead of unpacking bsas - they could disable auto-sorting for that mod which would have the same effect while being easier to revert.I want to assure you guys that I won't implement a solution that breaks current step-guides, my primary gole is to reduce problems for as many users as possible. This includes both step users and users that install mods without a guide.But the latter group will not have a tried&tested installation order to follow. They install the mod, either as a esp+bsa bundle and rely on loot to sort it correctly or they follow the mod authors instructions which will be written with NMM in mind. Ideally they would largely apply to MO as well.That's why my solutions may seem more complicated than necessary: I'm not only thinking about how to solve the immediate problem that mod-bsas can't be loaded interleaved with official bsas, if I'm going to implement something complicated why not kill two birds with one stone. For BSA mods this is not a problem, because esp bsa is a one-to-one mapping. Each bsa would be in the right place as specified by the plugin-order (which is the same as NMM would have placed them which is the same as what the mod author probably tested) and the mod order is irrelevant. MO would still have to place it somewhere, maybe aligned with the largest esp (in terms of filesize) or the first esp when ordering alphabetically. It's arbitrary but that doesn't matter, because, again, the mod order has no impact.For loose file mods MO would probably apply the same mod ordering (i.e. by largest esp). This is still arbitrary but less so than installation order! Unless you have a guide telling you where to place a mod this solution is still better than having mods simply appended to the end of the list and if you have a guide all you have to do is toggle auto-sort and do as the guide tells you.

@TechAngel85: Why does the step guide need to be installed in a certain order? Is there documentation on which conflicts step resolves in a certain order and why? The installation order is only relevant if there is a conflict between two mods, otherwise the order there simply doesn't matter. For the cases where two mods conflict and the order of the resolution is important (not down to preference), step should probably be very very careful proposing anything other than the plugin-order anyway. Think about it from the perspecive of the mod author: If he knows his mod contains scripts that conflict with scripts from other mods and thus may break the game HE will have to ensure users install his mod correctly. He could either provide an installation guide and hope people follow it. In this case step should follow his suggestion. Or he could package the scripts and other assets in a bsa so that loot does the asset ordering to ensure users get the mod installed correctly. The latter will work for people who don't extract BSAs and don't use MO, which should be the majority. It should never be necessary to unpack a BSA (or overwrite its load order) to get a mod working! In this case step should not suggest users unpack the bsa and order it contrary to plugin order, that would basically be saying "we know better than the author". This leaves mods where the install order is down to preference it may be possible to provide the right order through a boss/loot userlist provided by loot. OR step would have to tell users to deactivate auto-sorting for that mod and where to put it then. Long post short: Yes, MO would then move mods around based on plugin order. And it should not be necessary to turn this default behaviour off as it IS the usual behaviour for esp+bsa bundles when used outside MO. This IS the case the mod author has tested for and wrote his installation instructions for.

Hard links are even less of an option because they can only link within one drive. junctions aren't an option because they only work on directories. Symbolic links don't work because they require elevation. Doesn't matter, it's one possible use of the tool we would lose, in addition to the additional complexity for the user plus the elevation problem -> not going to happen. right This wouldn't be a supported option any more. We have already determined that having both managed BSAs and plugin-loaded BSAs is too complex. There isn't an asset tab, there is only a BSA tab which controls only the bsas on/off state, while their order (by default) would be determined automatically. And you wouldn't manage assets at all unless you specifically enable that for a mod and then you would use the same UI as you always have. You could still disable the dummy plugins, both BSAs would be loaded if they are checked on the Archives tab the same as they always have. You wouldn't manage their priority manually, that would still depend on the order of the plugins even if they are disabled. LOOT (and BOSS) does order disabled plugins! No you wouldn't because LOOT is already aware of it. If it isn't, the BSA would be loaded in the wrong order for ALL mod managers, not only MO. Not a problem, because MO would already sort mods in the same order as BSAs and plugins No, you won't be able to user-manage individual BSAs, either you manage the whole mod or none of it. If you want to extract a BSA you delete (or rename) it afterwards to avoid any confusion on what gets loaded (even though MO would ensure the loose file overwrite the BSA) This is not going to happen. You either let MO manage the mod manually then the BSAs are ordered in plugin order and loose files within a mod overwrite the bsas of that mod and all of lower priority or you manage manually then you specify BSA ordering for that whole mod and mod priority manually and loose files within a mod will still overwrite the bsas of that mod and all of lower priority.In essence: For auto-sorted mods you only ever manage one list: plugin order. For user-sorted mods you manage three lists: plugin, archive, mod The bsa and the mod would follow the plugin order, user managed entries would simply keep their original priority.If your order isA (plugin managed)...B (user managed)...C (plugin managed)And then C is moved above A then the order might becomeCABor, if B was directly below A:CBA

But we'd now have 3 "orders" to manage instead of one or two. The system needs to be easy in the common case (which does include the unofficial patches) and complicated only in the special case (I rather want this leather armor texture than the other) But the "Potential mod order problem" suggestion would tell you that the unofficial patches need to go between the dlcs! What you have to realize is that the conflict resolution loot does (which, in the vanilla state also sorts BSAs) decides game stability. It is important! The conflict resolution you can do manually, changing mod order on the left, should be purely a matter of taste. No mod consisting of loose file should assume to be installed in a certain position!The left pane in MO is for customization, there shouldn't be a "necessary" order to get your game running and if there are dependencies, MO should tell you and you should follow dependencies. The need for game stability beats the wish to customize.And therefore there wouldn't have to be a "ignore sort order" button. You would have auto-sorted mods and only for individual mods you could disable it if you absolutely know assets and plugin can be ordered independent of each other..This isn't good only for know-nothing modders, it's good for all of them. Customize only what you know can be customized

@z: Of course there would be a way to customize the load order. There's also the userlist for loot so you can also influence plugin order manually.re your edit: that's pretty much the problem: You can't think of managed BSA assets as loose files if there is a plugin-loaded bsa. loose files overwrite plugin-loaded bsas, managed bsas can not.@fireundubh: sorry, yes, I was confusing junction points with symbolic links. But you're wrong about the access rights: According to wikipedia: "The default security settings in Windows Vista/Windows 7 disallow non-elevated administrators and all non-administrators from creating symbolic links."This can be changed, but I won't ask users to first modify their windows security settings before they can use MO.And MO is designed to be portable. You can put MO and all your mods onto a usb stick, take it to a friend, run your whole mod setup on his computer. And on usb sticks non-ntfs filesystems are still common. crazy? I'm way past that. ;)

I'm afraid it's more convoluted:[*]Registered (official) BSAs [*]All managed (ticked/checked) BSAs -and- loose files (1), loaded according to MO's mod priority/"install" order [*]All un-ticked/un-checked BSAs not managed by MO, loaded according to their corresponding plugin order [*]loose files (2) [*](1) is loose files that conflict with managed BSAs or other loose files (2) is loose files that conflict with plugin-loaded BSAs but not with managed-bsas. They will win against plugin-loaded BSAs no matter the order of either the mod or plugin but they won't win agains managed bsas of higher order even though the plugin-loaded bsas would win against the managed bsa.

@z: false esm aren't the problem, the problem is that these unofficial esms are supposed to be loaded before official content. I haven't come across any mod for fallout 3/nv that expected to be loaded before official stuff. Sorry guys, symbolic links / junctions are not an option. - They require administrator rights to create, MO was explicitly designed to run with restricted rights. - They don't work on FAT HDDs (admittedly those are becoming increasingly rare) - Windows Explorer, at least in previous windows version, doesn't deal well with junction points (demonstrated - among other things - by the fact you can't create junctions inside the primary file management tool of windows). They are also not well understood by many users and third party tools. This just gives me a a vaguely bad feeling about the approach. Users might end up in a situation where they can't clean up properly without tools integrated in Windows or they might end up deleting files when they only intended to remove the junction points. I also don't like the idea of treating the unofficial patches special because they are third party, unofficial content after all. There is no way of knowing if the problem ends there, there might be other mods that expect to be installed before the official content or before the unofficial patches. I might end up continuously adding exceptions for mods and if I ever stop developing MO things would deteriorate. Treating the DLCs as mods is a far more feasible approach because the number of official DLCs is a lot more manageable than that of the unofficial stuff. TheBlokes proposal seems rather feasible but it means quite a bit of work for me and it still won't setup things correctly for users by default. I came up with another idea but this is an even bigger change. But first the rationale: Right now MO enforces the distinction between mod order=installation order=asset order vs plugin order. Its BSA management is there so bsas that would usually be plugin-loaded and therefore in plugin order (contrary to loose files that are in mod order) also become mod ordered. I still think think it's reasonable to not have a different order between loose files and bsas. However, in the vanilla system if there were no loose-file mods then in the default game there would only be one order to manage: plugin order. That's not bad either... Could we transfer this to MO? We could have all mods (that contain plugins) by default be "auto-storted". All auto-sorted mods are automatically put into the same order as the contained plugin. I would also change the bsa list into a flat list that is also auto-sorted by plugin order. This means MO would no longer prevent bsas from begin loaded interleaved with those from other mods/the core game. By default MO would then behave like the regular game: assets are loaded in the same order as the corresponsing plugin except this would apply to ALL assets including loose files. This means by default the user manages only one order: plugin order - which he can delegate to LOOT. Therefore he will by default have a working install. Of course he can still re-order mods that have no plugin (pure replacers consisting of loose files). He can still disable dummy esps. And if he really wants he can disable auto-sorting for individual mods to take control of their mod order, but then he will have to manually look after the bsa order for that mod as well. This provides a system that should work well by default and can still be customized. Opinions?

well actually, this can be simplified to "asset priority load order is all BSAs and loose files, loaded according to MO's mod priority order" or "asset priority order is mod priorty order"There is no need to make a distinction with registered BSAs because the actual data folder has implicitly the mod priority 0. And "managed" BSA doesn't have to be mentioned as that was part of the precondition. No, its actually worse than that because a "managed" BSA (let's just call them that) can overwrite loose files if it has higher priority but not a priority-loaded BSA. For some reason (one I never understood) the update.bsa appearing in the list confused some people - a lot - so I hid it. the update bsa is loaded by the engine hard-coded so it's a completely separate thing. It's another thing users have to know about. Something they have to do manually to get a correctly working game. These things never work out for all users (actually they usually don't work out for the majority of users), we will still have users with a broken game and they will still go to Arthmoor or me and ask why their game is broken and Arthmoor will continue to tell people MO is at fault.It allows users to fix the problem but it isn't fixed by default. Most users will probably install the unofficial patches so the installation is broken by default, this is what we have to get away from. If the user does nothing apart from installing a couple of mods and run loot the installation needs to be ok. MO may then offer features to break it again if people feel like it but that has to be a conscious decision on their part. I could still show the conflicts but it would be rather pointless because loot/boss would then be responsible for putting bsas into the right order and loose files would always overwrite bsas so you really wouldn't have to worry about conflicts with bsas (nor would you be able to do anything about it)

No, sorry, this was misinformation on my part. loose files will still overwrite plugin-loaded bsas. MO allows manual BSA management because there was always the fear that there might be mods that need to be loaded the traditional way. Still, solution 1 I proposed above (and was planning to release) is not feasible: a MO managed BSA can not overwrite a plugin-loaded BSA while loose files do. This means that the moment you have a single BSA not ticked in MO you're in a worsened asset mess of registered bsas vs loose files vs plugin-loaded bsas vs MO managed BSAs. Leaves us with the solutions 2. remove MOs BSA management 3. plugin to import dlcs as MO mods 4. hope for the unofficial patch guys to sort out the mess 5. install unofficial patches manually, outside MO 5 is a mess, 4 isn't going to happen, 3 goes against the paradigm that MO leaves your data directory alone. "leaving the data directory alone" isn't only about keeping the game in a vanilla state, I want MO to play nice with other mod managers. But if we remove official dlcs from the data directory that effectively "breaks" the game if you run it without MO and should bethesda decide to update dlcs your imported, now-outdated variants overwrite the updated dlcs. The DLCs are, as someone else mentioned, effectively mods. But they are steam-managed mods, not MO-managed. This leaves 2 as the only feasible solution, right? Remove the archives tab and all connected functionality and MO works like other mod managers in this regard, get rid of the whole controversy. This of course leaves the BSA extraction vs. Unofficial patch problem untouched but that's really not my fight...

The plugin-loaded BSA always wins. Now that I think about that this won't actually fix the problem completely, right? If the unofficial patches are plugin-loaded and all other bsas are "MO managed" aka "ticked", nothing will be able to override the unofficial patches. Of course this is already true if you unpack all BSAs except for unofficial patches...

There are multiple solutions, don't know which is more real.1. Have MO not apply its "magic" on the unofficial patches, thus having them load like the unofficial patch team intended. This is the simplest solution for everyone involved, only drawback is that it breaks the clean layering of mods in MO, at least for these mods 2. Remove the "magic" regarding BSAs from MO completely. This is a radical step as it will invalidate a lot of documentation we have and it would mean that MO users would again have to concern themselves with plugin bsas vs. loose files vs registered bsas 3. We could write a MO plugin that extracts the dlcs from the data directory and puts them into individual mods, thus automating the step proposed further up in this guide. 4. The unofficial patch team could release different variants of their plugins depending on the set of installed dlcs. re 4.: My understanding is this, please correct me if I'm wrong: The load order (as an example) Skyrim.esm USKP.esp Dawnguard.esm is necessary because USKP contains script fixes for the vanilla game that are not compatible with Dawnguard so they need to be replaced by the dawnguard content. The only reason USKP needs to be loaded before DLC stuff is because the DLCs need to be able to overwrite stuff from unofficial patches, correct? Now if instead of releasing one patch for skyrim, one for dawnguard, one for hearthfire and one for dragonborn they could release one patch for skyrim - no dlcs skyrim - all dlcs skyrim - dawnguard only skyrim - hearthfire only skyrim - dragonborn only skyrim - dawnguard + hearthfire skyrim - dawnguard + dragonborn skyrim - hearthfire + dragonborn things would become a lot easier for users: Sure, this is 8 patches instead of 4 but they could have a fomod installer where you can pick the right one. Users would then only have one mod to download and one esp in their load order (instead of up to 4). Third party stuff would again be loaded strictly after official content and everything would be good. What's the "realest" solution here? I really don't know, considering how uncommunicative the unofficial patch team has been I'd assume the fourth solution is simply wishful thinking and won't happen.

Nooo, MO doesn't treat the dlc special. It also doesn't treat the grayed out bsas special.The grayed out bsas are only grayed out because they are listed in the ini file and are therefore probably required by the game. The problem is, again, actually quite simple and not caused by MO doing anything special: MO is based around the assumption that official game content (everything in the data directory) is loaded first and mods work as overlays to that. The mod isolation feature enforces this, it ensures that each mod is a separate layer on top of the game (both physically as well as logically) NOT mixed with the original content. That's what it's all about and this is how I developed features (hence controlling BSA load order made sense at the time I developed it) And this assumption was valid for years for four different games until the unofficial patches decided to be loaded interleaved with the official content. MO enforces that mod assets are loaded after the dlcs whereas loot (and the suggestions from the unofficial patches) make you load the plugins interleaved with the official stuff. the unofficial plugins have pretty much "elevated" themselves to the same level as the official content. It's not MO doing anything special, its the unofficial patches that want to be treated different than other mods. These three mods effectively break a logical order that has been applicable since Oblivion (probably even Morrowind) I'd also like to point out that for all the ranting Arthmoor has done agains MO he has never contacted me about his concerns. I have never had a bug report that MO might be causing this kind of problems. No one has contacted me with constructive feedback on the topic. As someone who hasn't played Skyrim in over a year I don't stumble about these problems myself anymore. So if people in the know had actually talked to me instead of ranting in secret this could have been solved a long time ago. MO has existed before the unofficial patches were even started. It has existed when the unofficial patches teams decided to make them fake esms that need to be installed between official stuff. THEY could have determined this causes problems with MO months before I ever had the chance. THEY could have made me aware of the problem way before releasing and given me a chance to solve it before it ever affected anyone. Instead they release, then rant, then wait for users to propagate the issue to me. THIS is why the problem isn't fixed yet, NOT because I did anything extraordinary. Now this was my pointless rant, how was it? Constructive much? The best solution I can suggest now is: Don't unpack the unofficial patch bsas and don't tick their bsas on the archives tab! Ignore the warning sign (it will be removed in the next MO release). The next version of MO will also no longer suggest users tick the archives by default, it will make it clear that this is only necessary (and reasonable) if you actually want to take control of the asset load order of that mod. This, combined with the fact that BSA extraction will by default be disabled will hopefully reduce the number of problems for beginning users, now it's mostly important that we all don't advertise those features to users unless they actually understand what they're about.

Well, maybe, I can't keep you from looking into the details, but if you're going to start documenting stuff that isn't relevant to the average users and may be confusing as hell then at least put a f***ing big note at the very top saying: "If you're a regular user you don't need to know this and unless you have a CS degree or an equivalent amount of computer experience you're not going to understand it".I don't want the average user to think about this kind of stuff because it's me who'll get all the bothersome questions. thanks :) I can understand that but I develop MO for anyone who wants to do modding and needs to have more control. What we actually need is several documentations:- If you're new to modding, here is what you have to know- If you're an experienced modder who hasn't used a manager before, here is what you have to know- If you're a converting NMM user, here is what you have to know- If you're a converting Wrye Bash user, here is what you have to know Sure, but my expectation is that someone who is into modding and spends a considerable amount of his time on the topic is going to read the documentation available whereas someone who only cares about higher-res textures and more bad-ass dragons is not going to read a lot because his prime interest is playing the game not tinkering with it.Hence I try to optimize my UI for the second group and expect the former group will find their information in "what's this"s and the wiki. I'm still convinced that everything discussed in this thread has already been sufficiently explained inside MO and outside as long as you trust that my documentation doesn't lie to you.However if you go I really can't help you.