KR mod structure

[subtledoctor]

@Subtledoctor, Kreso counted a crazy amount of install options because the whole discussion started from you crossing your fingers for a kit-by-kit solution (see your first post). A class-by-class install is much more reasonable imo, and I think that's what I will be doing.

 

D'oh!! So in other words, my poor phrasing ignited a bonfire. Ouch, sorry. That's not actually what I wrote, though the writing was indeed ambiguous. That original post was really meant to ask, will the installer stay as-is, or have more granular options - fingers crossed for more granular options. "class-by-class, or even kit-by-kit" was just an example tossed out to clarify "more granular options," but I didn't mean to advocate anything specific in that post. As I agreed later, a kit-by-kit approach would be fairly ridiculous.

 

@kreso, I do think there is a happy medium. My mod, currently in beta status, has ~40 components, which is a lot. But that includes 16 new kits, (which kind of have to be asked one-by-one because of the 10-kit-per-class limit), and about 12 components for NPCs (which I might restrict to EE games, since vanilla players can and should use L1NPCs.) That leaves about a dozen other components, not so bad. I'm considering whether and how to trim/combine things, which is why this is on my mind.

 

But the flip side of the coin is something like IA as you mention. Yes it's easy, but there is no engagement. Frankly having the user press 'i' a dozen or so times at least gets them to look at the component titles and see what they're doing, which can be valuable if they haven't bothered to read the Readme. And on the player's side, they get a sense of being an active participant in the process, tailoring the game to their own preferences.

 

Tweak mods are in essence, applying your own "house rules" to the game. It seems like you would advocate (for instance) that Demi should combine the XP component and THAC0 component and saving throws etc. into the 'core' installation. But if there's no technical reason they can't be separate, why not let the player choose whichever house rules they want to play with?

 

And btw when a mod has more than 10 components, Weidu by default will ask the player if they want to just install everything. Hit 'i' once and bam, it all goes in. So even with 40+ components, ease of installation is not lost.

[kreso]

(which kind of have to be asked one-by-one because of the 10-kit-per-class limit)

I think ToBEx allows you to expand the selection (add a scroll bar). It's free to distribute with mods, thus you can use it, if you like.

[Jarno Mikkola]

And btw when a mod has more than 10 components, Weidu by default will ask the player if they want to just install everything. Hit 'i' once and bam, it all goes in. So even with 40+ components, ease of installation is not lost.

Well technically there's an option to prevent that... and the fact that the one mod asks 90 questions about things is due to the fact that they don't take [Y]es/[N]o answers to install a simple component, but how it get's installed: "push x","push y","blarg"...

It good to a point, but after that it gets jarring. Without auto installers.

 

 

(which kind of have to be asked one-by-one because of the 10-kit-per-class limit)

I think ToBEx allows you to expand the selection (add a scroll bar). It's free to distribute with mods, thus you can use it, if you like.

 

Yes. And comes internalized in the BGxEE games.

[subtledoctor]

(which kind of have to be asked one-by-one because of the 10-kit-per-class limit)

I think ToBEx allows you to expand the selection (add a scroll bar). It's free to distribute with mods, thus you can use it, if you like.

 

Yes. And comes internalized in the BGxEE games.

 

 

Actually no, *some* of TobEx comes internalized in the EE games. A lot of it isn't. Installing more than 10 kits per class in EE makes the 11th and later ones unavailable to the player. (I had actually just tested this.) My mod isn't just for TobEx players, it's for all players, so I have to make a compromise there. A slightly more onerous installation process, in exchange for giving players more and better choices.

 

Of course some of my kits overlap with some of the S&S kits, thematically... so I suppose I could just add some code that says "if the player installs the SoB Sniper thief kit, disable the S&S Sharpshooter kit to make room for it." They are after all "conceptually incompatible" in a similar fashion to KR and DR; and that way it would create a situation where the last to be installed "wins." But... to mess with something installed by another mod just seems rude. Easier and friendlier to simply add a few installation components and let the player choose to install one or there other or both, as they see fit.

 

And of course the actual number of components is pretty arbitrary, because I could simply split my 40-component mod into 3 separate mods of 13 components each. Each would seem more reasonable in that regard, but the end result would be literally the same. I mean Demi could package up KR and SR and IR and give everything a single yes-or-no install option, like IA... but would anybody really advocate for that?

 

Like I say, I think there's a happy medium, I just started this thread to discuss where that might be.

[kreso]

I just started this thread to discuss where that might be.

I don't really know. I know of a few players that do want "hand-picked" options, and don't mind dozens of choices.

Likewise, I know of many who don't want to bother (ex: my brother plays BG once every year or so, and doesn't really have any underlying understanding of the game; doesn't really want to be bothered with install options he doesn't understand.)

Hence- some middle ground should exist, but as the mods grow larger, middle ground gets harder to find.

The "in-thing" today is allowing for extra options either via .ini file or via CLUAConsole.

I'm not sure if this is good or not (end-users may not like to bother editing, and purists won't even activate CLUA).

[DavidW]

I think both .ini and CLUAConsole are my idea originally, so here's my rationale for doing it this way:

 

1) a mod like SCS inevitably isn't going to have a single "preferred" way to play it. A lot of the appeal of the mod is that people can customise it to their preferences.

On the other hand:

2) the sheer number of customisation options in SCS is ridiculously large, especially given the number of little things I've put in to respond to various requests; and

3) I think there is some reasonable expectation that anything you can choose with the standard installer is something that I at least think is reasonable.

 

So the CLUA and .ini options are my way of allowing power users extremely fine control of the install process, without forcing all users through a 300-option tp2 list and without causing people who read the readme casually to wreck their game through poor choices.

 

In the future, if anything I'd like to go further in the direction of helping relatively-casual players. I already have functionality to let players choose to install all components in a given section; I'd quite like to let people choose from a list of streamlined "recommended installs" or something. WEIDU isn't that cooperative with this sort of thing, unfortunately.

 

(Jarno objects that he doesn't want to learn a new install method. That's fine; no-one has to learn it. It's for those who want more customisation than I'm willing to put in the TP2. The alternative to the ini file isn't more TP2 options, it's less customisation.)

[Jarno Mikkola]

(Jarno objects that he doesn't want to learn a new install method. That's fine; no-one has to learn it. It's for those who want more customisation than I'm willing to put in the TP2. The alternative to the ini file isn't more TP2 options, it's less customisation.)

Well, in my opinion this is more about the mod installing in general than about any particular mod. Now when you say that it's less customization options in the tp2 vs .ini ... I find it hard to believe.

And yes, I have about 2000 ticks I need to check when I make my BG2 mega-install, not close to the 90 or the 300. Power use that.

 

You do have a point, but the ... hmm,

WEIDU isn't that cooperative with this sort of thing, unfortunately.

Here's an idea, you could make a quick install tool and a custom install tool(well the actual .tp2), the quick install tool would comprise of starting a select groups of predefined install .bat's that install lists of things in the normal install, while the custom install let's you choose component by component. Bad idea, yeah, want more ? Just ask... This allows better customization on a megamod level as instead of using the predefined .bat's, the user gets to use his own list via similar file.

 

This is different from the .ini's how, well it never blurs the line forcing you to customize the in mod files(.ini's) when you would install using a custom setup.

PS, let's remember that this is not about SCS, but KR's mod structure we are talking about. LATE EDIT:Ouh, apologies for steering this discussion off the topic.

[kreso]

I'd quite like to let people choose from a list of streamlined "recommended installs" or something.

GL with that...with all the possible stuff SCS can improve on, I can't imagine what you'd recommend for SCS without huge dificulty spikes if you leave something out.

Example - I find Beholders to be incredibly annoying and hard. Sure, you've got options to deal with them (most notable Greater Command) but still; that's one part of my install that makes me "think twice" before tackling it. Otoh, if you leave Beholders out of install, I feel as if they're too easy.

Same could be said to demons - a mage without spell protections whose HP is slightly below treshold for PW:Stun is gonna be shredded in no time. (think Drow gate battle).

Then again, without those, mod wouldn't feel as "whole".

[DavidW]

And yes, I have about 2000 ticks I need to check when I make my BG2 mega-install, not close to the 90 or the 300. Power use that.

Yes, I can see for megamod installs that there are so many options a few more don't matter. But I'm mostly aiming at non-megamod installations, and at people who are going to install directly rather than via BWP or similar.

[CamDawg]

 

but wants to use Divine Remix

You took a very bad example. DR (unfortunately) is uncompatible with pretty much everything, including KR Rangers and Paladins (one has to use a specific install order, and even then, they're not in the Sphere system...).

Second, I don't know why KR should aim to be "compatible" with mods that do the very same thing. By default, it should be incompatible.

 

DR has had libraries for any mod to bring their kits inline with DR's sphere system pretty much since its inception; it's used in SP Collection for its divine kits, and it will happily detect other divine kits and apply the (base) spheres for the class to them. Spells can be handled simply by adding them to the right sphere libraries and re-applying.

 

At its core, though, you have to understand that there are two types of incompatibilities. There's incompatibilities because modders don't care or understand how to make things work, and then there's incompatibilities because the concepts behind mods conflict. DR and SR/KR aim to rework, at a pretty fundamental level, how divine magic and kits work. I'm sure we could find a way to stitch them together in a working fashion, but it's also entirely possible that neither Demi or I would be satisfied with the result.

[kreso]

but it's also entirely possible that neither Demi or I would be satisfied with the result.

That's a shame, since I love both SR and DR.

[subtledoctor]

That's a shame, since I love both SR and DR.

Ditto. I never would have released a mod with cleric kits if it wasn't so hard to use DR with SR and EE. It was easier to roll a handful of new kits than it was to implement SR-style spell tweaks, so DR 'lost' that battle. (Though, I am interested in adding DR compatibility to my kits for vanilla non-SR users. I'll look into that.)

 

Here's an idea, you could make a quick install tool and a custom install tool(well the actual .tp2), the quick install tool would comprise of starting a select groups of predefined install .bat's that install lists of things in the normal install,

Actually you could do something like this in Weidu, just start the mod off with a subcomponent group,

How do you want to install the mod?
 - [n] Minimal install 
 - [r] Recommended install
 - [x] Maximum install
 - [c] Custom install, ask about each component
 - [q] Quit

...where each of the first three defines a set of components to install. I'm pretty sure you could make that work... whether it would be worth the effort is another question. And not applicable to KR in any event, as it is likely to only have ~15 components at the very most.

[DavidW]

 

That's a shame, since I love both SR and DR.

Ditto. I never would have released a mod with cleric kits if it wasn't so hard to use DR with SR and EE. It was easier to roll a handful of new kits than it was to implement SR-style spell tweaks, so DR 'lost' that battle. (Though, I am interested in adding DR compatibility to my kits for vanilla non-SR users. I'll look into that.)

 

Here's an idea, you could make a quick install tool and a custom install tool(well the actual .tp2), the quick install tool would comprise of starting a select groups of predefined install .bat's that install lists of things in the normal install,

Actually you could do something like this in Weidu, just start the mod off with a subcomponent group,

How do you want to install the mod?
 - [n] Minimal install 
 - [r] Recommended install
 - [x] Maximum install
 - [c] Custom install, ask about each component
 - [q] Quit

...where each of the first three defines a set of components to install. I'm pretty sure you could make that work... whether it would be worth the effort is another question. And not applicable to KR in any event, as it is likely to only have ~15 components at the very most.

 

Interfacing this with SCS's extant component structure is harder than you might think...

[subtledoctor]

Interfacing this with SCS's extant component structure is harder than you might think...

 

Oh I didn't mean for SCS specifically. I just meant Weidu can technically do it, without resorting to things like .bat scripts.