Jump to content

Recommended Posts

Posted

Basically the way it's set up now, they get only the strings they need and nothing else. It's still multilingual, it's just not installing unneeded language files and only installing the languages the user wants. Windows is multilingual as well, but you don't go installing all the available languages do you? I doubt it... You only install the languages you need and nothing else. I don't see the point in installing those unneeded files and if there is no point to them for user that will not need them. What is wrong about allowing the user to choose the language(s) they want and then move on to the rest of the mod installation?  Everything comes down to user choice and freedom and the way the FOMOD is set up now (version 2) allows this for the user for all files associated with Soul Gems Differ (except for the Core files; which are installed without choice because they are required).

 

Whether I do it the way I'm doing it (which is nearly already complete) or forcibly install all the associated string files, the end result is the same. The user still gets the language support they need "out of the box" with one install. Unless someone can prove this would not be the case, then I see no reason to change what I've already done.

 

I know I'm being a bit stubborn on this but when I know the end result is the same for the user, I see no point in changing the code (for the third time) for such a small detail. It's like asking a plumber to install a sink then asking him to redo it to install a third knob that is never going to be used and serves no purpose. (The plumber would do it most likely because it's your money and he's getting paid...I'm not). See my point?

 

EDIT:

Version 2 is complete, tested and working perfectly (even for multi-language installs)...

Posted

I see your points Tech, but I would mention that we are currently talking about sticking more to standards and best practice, and that multilingual mod "best practice" is to install all applicable languages for simpler user switching and simplified installation. Not that big a deal if you are already done though, but you are probably deviating to 'Tech' standards ;)

Posted

I see your points Tech, but I would mention that we are currently talking about sticking more to standards and best practice, and that multilingual mod "best practice" is to install all applicable languages for simpler user switching and simplified installation. Not that big a deal if you are already done though, but you are probably deviating to 'Tech' standards ;)

From what I can tell from Nexus, most mods that provide additional language support do so in the form or providing files under their "optional files" sections; thus, allowing the user to only install the languages they need. I'd need examples of mods that do what you are saying before believing that is the standard practice because what I am seeing tells me differently. In fact, I have yet to find a mod that does as you guys are suggesting (granted I haven't look that hard or for that long).

Posted

The Unofficial DLC patches notably use the approach z92 and I have been describing by packaging the translations into the BSA. Book Covers Skyrim also does the same thing regarding localizations. And we should be doing the same as those two mods.

Posted

I am sure that most mods do not follow standards, but that is a problem. The USP team basically sets the standards, since they worked directly with Bethesda point person(s) to establish modding standards for Skyrim (which never really was done for Oblivion and Morrowind).

 

Like I said, writing up an installer is a PITA, so I'll take what I can get.

Posted

If that is the 100% set in stone standard, then I will rework the FOMOD to use it. Won't take that long really. As you said it, it's just simply a PITA to do. I'll have it reworked shortly.

Posted

Hmm... I can see many improvements can be made, notably by making the structure BAIN friendly, and also using the ConditionalFileInstalls feature of NMM installers to reduce duplicate code. I'll come up with something with those changes pretty soon.

Posted

Hmm... I can see many improvements can be made, notably by making the structure BAIN friendly, and also using the ConditionalFileInstalls feature of NMM installers to reduce duplicate code. I'll come up with something with those changes pretty soon.

The BAIN structure is still there, just one level deeper. I did that to make it easier to manage. I also left the wizard in there because I had planned on reverting that back eventually for an all-in-one installer. It can be reverted within an hour probably. I'd like to know where you learned ConditionalFileIntalls. I've learned everything I know from using other FOMODs as a reference and this guide. Neither that guide or the FOMODs I've referenced use or states anything about those.

Posted

Actually, I learned ConditionalFileInstalls exactly from that guide, and you are actually using it in a limited fashion in the current FOMOD. It's one of the most powerful tools at your disposal for FOMOD writing, and it's a complete shame not many people use it to the full potential.

Posted

Actually, I learned ConditionalFileInstalls exactly from that guide, and you are actually using it in a limited fashion in the current FOMOD. It's one of the most powerful tools at your disposal for FOMOD writing, and it's a complete shame not many people use it to the full potential.

I assume you're talking about the conditional flags and running a section of code depending on which flags are active?  I guess I don't know it's full potential then because I thought I was using it as it is suppose to be used. If you rework the code, post it so I can learn what you are doing and better my skills.

 

I do want to point out I had to reset the "custom" flag from On to Off at one point to prevent some unwanted options showing up. It's around the glow texture bit in the code (possibly right before). This was the only way I could prevent the glow options from showing when the user chose not to install them.

Posted
Here's my updated version. Now with more BAIN friendliness and less duplicated code in the installer! In fact, z92 would have a much easier job on his hands considering that nearly all of the directory names are the same as they were in the BAIN installer originally (didn't have to rename much, too)
Posted

Here's my updated version. Now with more BAIN friendliness and less duplicated code in the installer! In fact, z92 would have a much easier job on his hands considering that nearly all of the directory names are the same as they were in the BAIN installer originally (didn't have to rename much, too)

Not working... your version just installed 8 different ESP files, a ton a string files and installed the 000 Core folder rather than the core textures... I haven't looked at the code yet. Did you even test it? ::P:

 

EDIT:

yeah...I think I'll stick with my version, but I will convert it back to the BAIN file structure. It's working and your rework is ever longer than the original. They would probably accomplish the same thing in the end but mine seems to be more stable at the moment. I guarantee that it will work with all possible install options.

 

I see what you did with the dependencies. I wasn't too sure on how those worked and I knew MO has had trouble with it in the past so I just steered clear of those and made it a bit more basic which ironically resulted in a few less lines than all those dependencies. I could play around with it to see if I could get it to work probably if I could understand how those things worked exactly.

 

Not exactly my kind of music, btw. ::P:

 

EDIT 2:

I fixed it. You had "flagDependencies" when it should have been "flagDependecy". Looks like it's working now but will do so more testing later. Honestly there is no real difference between the two. As a said above, your rework is actually a tad longer. Also this bit:

                            <typeDescriptor>                                <dependencyType>                                    <defaultType name="Optional"/>                                    <patterns>                                        <pattern>                                            <dependencies operator="Or">                                                <fileDependency file="Requiem.esp" state="Active"/>                                                <fileDependency file="Requiem.esp" state="Inactive"/>                                            </dependencies>                                            <type name="Recommended"/>                                        </pattern>                                    </patterns>                                </dependencyType>                            </typeDescriptor>

is completely redundant and pointless it would seem. You're basically telling the FOMOD that this option is recommended (selected) if the Requiem.esp file is either active or inactive and as long as it's not missing. However, I don't know if it's a MO thing or would give the same results in WB as well, but it doesn't work whether or not the ESP is present because it gives no warning like it should if you change the selection (according to that guide it should throw a warning). Also, you get the same result in my code without this bit...so it's basically just useless code (at least for MO).

Posted

The bit of code you singled out is actually autoselection code ripped from my EBQO FOMOD installer. In that, if Requiem was installed, the patch for it would be automatically selected, no frills. In this case, actually, it may be a little redudant. The intention is to select the Requiem option if Requiem is installed, and select the non-Requiem option if it isn't - I've used a similiar statagey for my Disease Descriptions FOMOD installer when regarding RN&D, and in there, it does work fine (at least with the external/NCC installer).

Posted

The bit of code you singled out is actually autoselection code ripped from my EBQO FOMOD installer. In that, if Requiem was installed, the patch for it would be automatically selected, no frills. In this case, actually, it may be a little redudant. The intention is to select the Requiem option if Requiem is installed, and select the non-Requiem option if it isn't - I've used a similiar statagey for my Disease Descriptions FOMOD installer when regarding RN&D, and in there, it does work fine (at least with the external/NCC installer).

Didn't try it with the external installer; however, there is no need to use it so I wouldn't want to instruct users to do that for no reason. It doesn't seem to be working with the internal installer as I tested with Requiem installed and not installed...exactly the same result. The first is selected no matter what. Do you know if this is different for WB users? If it is, I'll leave it. If not, I'm just going to take it out since it isn't working.

 

EDIT:

Neither yours or mine FOMOD will run on the external installer (unless I'm doing something wrong). No matter, it doesn't need the external installer.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.