81 replies to this topic

[DavidWallace]

I've been giving some thought to how to make use of ToBEx in other mods (SCS in particular) in as user-friendly a way as possible.

Case study: SCS has a component to allow antimagic spells (Secret Word et al) to bypass Improved Invisibility. There are three possibilities:

(1) User has ToBEx installed, has enabled component that creates a bypass-invisibility flag.
(2) User has ToBEx installed but hasn't enabled that component.
(3) User doesn't have ToBEx installed.

So...

In scenario (1), it's just a matter of detecting that the component is enabled. This could be done by conventional WEIDU detection; however (not least since it's so easy for power users to tweak the tobex.ini direct) it looks to me easier to use FILE_CONTAINS_EVALUATED (~tobex.ini~ ~Configurable Spells Can Target Invisible=1~). Is this right, or am I missing something?

In scenario (2) (having detected that the component is not enabled), I could just shrug and treat it like scenario (3). But is there any particular reason not to just do a REPLACE_TEXTUALLY on tobex.ini to activate the component?

In scenario (3) I could just fall back on a soft-code workaround - I'll have to for Mac users in any case. (For this particular component the workaround uses the invisible creature trick.) But I wondered about seeking permission to actually include a copy of ToBex inside SCS(II), checking if it's already present, and installing it if it isn't. (On a minimal install, obviously - only enough to enable what SCS needs.)

My overall thought is this. From a modder's perspective, ToBEx is remarkably liberating, but the current setup makes installation relatively complicated for end users: if I want to take advantage of a given ToBEx component, I need not only to require that ToBEx is installed, but to require the user to install a fairly unintuitively-named (for non-coders) and fairly esoteric-sounding component. If I were to allow SCS to edit tobex.ini, things get a fair bit easier: the user needs to install ToBEx, but doesn't need to configure it manually. If I ship ToBEx with SCS then the whole thing becomes transparent: the end user doesn't even need to know what ToBEx is.

An analogy: when WEIDU came along, we could as a community have gone for a model where the user has to download WEIDU before running any WEIDU mods. Actually, we just bundle WEIDU up with every mod, and the end user doesn't need to know what WEIDU is. This bloats every mod by 700kB, but it's easily worth it for a smooth end-user experience. If the ship-ToBEx solution is something Ascension64's amenable to, we'd potentially get in a situation where quite a few mods (not all, by any means) ship with ToBEx, adding a perfectly-tolerable 300kB bloat. It would be nice, in that situation, to have a WEIDU-type way to check that the most recent version is installed.

... thoughts?

[the bigg]

In scenario (1), it's just a matter of detecting that the component is enabled. This could be done by conventional WEIDU detection; however (not least since it's so easy for power users to tweak the tobex.ini direct) it looks to me easier to use FILE_CONTAINS_EVALUATED (~tobex.ini~ ~Configurable Spells Can Target Invisible=1~). Is this right, or am I missing something?

The INI should only be altered, after all mods are installed, to disable miscoded components (or for similar debugging purposes). If you make it an habit of altering it manually, then you deserve any bugs you might get (especially if readmes point out that altering tobex's ini manually might cause their mod to misbehave).

In scenario (2) (having detected that the component is not enabled), I could just shrug and treat it like scenario (3). But is there any particular reason not to just do a REPLACE_TEXTUALLY on tobex.ini to activate the component?

In this day of BWP and QUICK_MENU, if somebody didn't install component X it means he really didn't want it (or is an idiot who lacks the knowledge to properly configure ToBEx and still refuses to use the given aids).

An analogy: when WEIDU came along, we could as a community have gone for a model where the user has to download WEIDU before running any WEIDU mods. Actually, we just bundle WEIDU up with every mod, and the end user doesn't need to know what WEIDU is. This bloats every mod by 700kB, but it's easily worth it for a smooth end-user experience. If the ship-ToBEx solution is something Ascension64's amenable to, we'd potentially get in a situation where quite a few mods (not all, by any means) ship with ToBEx, adding a perfectly-tolerable 300kB bloat. It would be nice, in that situation, to have a WEIDU-type way to check that the most recent version is installed.

No, thank you. If people want simplicity they use the BWP; if they want control, they're still bound to download a dozen mods (name a person who installs SCSII alone or with just the BG2Fixpack), and adding an extra one doesn't add significantly add to the complexity (again, as long as the readme does spell out the requirement).

[DavidWallace]

if they want control, they're still bound to download a dozen mods (name a person who installs SCSII alone or with just the BG2Fixpack)

Well, I shan't name people, but actually I think I have quite a lot of users who use SCSII alone or nearly alone. (More of them hang out on the Bioware forums than at G3.) In fact, that's pretty much exactly the demographic I had in mind. I also think there's a difference between (a) just installing, say, seven or eight mods, and (b) having to navigate a chain of dependencies where some mod has to be installed not because you want a given feature, but because another mod needs something from the first mod.

Put another way: you're saying there's no space between BWP users and power-users who know exactly what they're doing. I disagree. At least on the surface, the WEIDU framework creates the impression that you choose your mods, you install them, and you pick the components you want - end of story. The closer we can get to making that a reality, the better. As it is, it more or less is a reality with modern-coded mods, except for some residual install-order issues.

Edit, after thinking about this more carefully:

In this day of BWP and QUICK_MENU, if somebody didn't install component X it means he really didn't want it (or is an idiot who lacks the knowledge to properly configure ToBEx and still refuses to use the given aids).

Or he doesn't know what it means (we're talking about highly unintuitive components that don't in themselves have in-game effects). Given your (laudable) belief that people who don't read READMEs can't complain when they get unwanted features, I don't obviously see why an SCS component shouldn't activate some piece of ToBEx, provided it comes clean about it in the README. (Of course, it's then my fault if so doing breaks something elsewhere, but that's not specific to ToBEx.)

Regarding detection: I'm still not clear why you prefer doing that via detecting ToBEx components. I wouldn't normally do this with other change- e.g. I wouldn't check for whether or not Fixpack's installed to determine if some CRE file has been changed, I'd just examine the CRE file directly.

Edited by DavidWallace, 01 February 2011 - 02:37 AM.

[Shaitan]

An analogy: when WEIDU came along, we could as a community have gone for a model where the user has to download WEIDU before running any WEIDU mods. Actually, we just bundle WEIDU up with every mod, and the end user doesn't need to know what WEIDU is. This bloats every mod by 700kB, but it's easily worth it for a smooth end-user experience. If the ship-ToBEx solution is something Ascension64's amenable to, we'd potentially get in a situation where quite a few mods (not all, by any means) ship with ToBEx, adding a perfectly-tolerable 300kB bloat. It would be nice, in that situation, to have a WEIDU-type way to check that the most recent version is installed.

As an enduser with almost no idea of what ToBex would mean to my games, I like this idea. I avoid BWP, and generally choose which mods I'd like to use an sort them in a list after which I installs them. If ToBex was clearcut as of what to do, I could probably just install it, but I'm sure the solution (if it is) DavidW propose is better.

Cheers

[DavidWallace]

An analogy: when WEIDU came along, we could as a community have gone for a model where the user has to download WEIDU before running any WEIDU mods. Actually, we just bundle WEIDU up with every mod, and the end user doesn't need to know what WEIDU is. This bloats every mod by 700kB, but it's easily worth it for a smooth end-user experience. If the ship-ToBEx solution is something Ascension64's amenable to, we'd potentially get in a situation where quite a few mods (not all, by any means) ship with ToBEx, adding a perfectly-tolerable 300kB bloat. It would be nice, in that situation, to have a WEIDU-type way to check that the most recent version is installed.

As an enduser with almost no idea of what ToBex would mean to my games, I like this idea. I avoid BWP, and generally choose which mods I'd like to use an sort them in a list after which I installs them. If ToBex was clearcut as of what to do, I could probably just install it, but I'm sure the solution (if it is) DavidW propose is better.

Cheers

Thanks. I'm not at all sure it's better, actually, I just wanted to put it up there for discussion.

[the bigg]

I would have never thought that single-mod users still existed. I will keep telling people to manually download and install ToBEx in my mods, but (if you want to cater to your non-BWP simple users) I think it's ultimately up to Ascension64 if he wants to do the required work (like adding version information to the DLL and other required bits to allow updating ToBEx between SR, SCSII and other mods that want to bundle it).

Also, the scsII readme states that the BG2Fixpack is an harder requirement than ToBEx (fixpack = not tested, bugs might happen; ToBEx = tested, X will happen in case Y); as such, why aren't you bundling the Fixpack with SCSII as well?

[DavidWallace]

I would have never thought that single-mod users still existed. I will keep telling people to manually download and install ToBEx in my mods, but (if you want to cater to your non-BWP simple users) I think it's ultimately up to Ascension64 if he wants to do the required work (like adding version information to the DLL and other required bits to allow updating ToBEx between SR, SCSII and other mods that want to bundle it).

I certainly wouldn't want to generate more than a trivial amount of extra work. If there's a smooth way to do auto-updating that Ascension64's happy to support, great. If not, but he doesn't mind me bundling, I can work around (it's easy enough to check via the ToBEx.ini if the version is up-to-date enough to include the components I need, to update if it isn't, and to tolerate intermediate cases as no worse than what would happen on the manual-install scenario). I'm even not-too-bothered about just saying "install ToBEx" in the SCSII installation instructions, provided I can safely tell the user not to worry about configuring it because I can do it for them.

Also, the scsII readme states that the BG2Fixpack is an harder requirement than ToBEx (fixpack = not tested, bugs might happen; ToBEx = tested, X will happen in case Y); as such, why aren't you bundling the Fixpack with SCSII as well?

It's a pretty fair point. I used to test SCS with Fixpack, with Baldurdash, and with neither, but I've fallen out of the habit. (And by now I think I'd stop bothering to support Baldurdash even if I did support no-fixpack - the Fixpack Wars seem to be over.) Actually, I know for sure that currently SCSII doesn't even install without the fixpack - in fact, the most recent help request I had was from a user whose install was just SCSII+Fixpack but who had them the other way around - and I don't think that's ideal, and will fix when I get around to it. But for reasons I can't entirely explicate, I don't think it's so much of a problem in that case as with ToBEx.

[Ascension64]

Lol, I'm a TobEx developer who doesn't know what TobEx will do to my games. Obviously, one major issue with bundling TobEx with your mod is that I cannot and will not guarantee stability. This is one of the biggest issues I keep wondering about how we can mitigate. At this stage, testing can only go so far, because a large number of players end up using a mega-complicated BWP install (which doesn't even install TobEx in the recommended manner).

If we assume many things, I would support including TobEx as part of an install. This would be akin to PlugY for Diablo II and OBSE in Oblivion. There are quite a few complicating factors though that differentiates TobEx from these other games:
1. PlugY and OBSE are standards that simply add things for use. Everyone who uses the same version of PlugY and OBSE get the same deal. With TobEx, there is so much configurability that there are currently 2^91 combinations of hacks that could be enabled/disabled. Some are tweaks that won't be suited to a 'standard'.
2. Diablo II is a single-mod single-game distribution, so modders can afford to use their own version of PlugY without interfering with other mods. Simply put, if players want to play other mods, they have to clone Diablo II. TobEx is similar to OBSE in this respect (a multi-mod single-game distribution), but because TobEx has to deal with compatibility issues with tob_hacks, SR, SCS, etc., this restricts the use of TobEx as a 'standard'.
3. TobEx isn't an independent program like PlugY and OBSE. It still requires WeiDU to modify some of the game resources and add new resources. Every mod that wants to use TobEx would need to make sure that these resources are installed.

In many respects, this goes back to what Salk had suggested at G3 about using TobEx as a 'standard'.

If we desire to head towards something more stable, I am more than happy to turn TobEx into a 'standard'. The core changes to the game (like bug fixes, extended effects, more triggers, new stats, etc.) will be non-configurable that are all installed in one fell swoop. If TobEx becomes a 'standard', it can easily be included with mods like WeiDU.

Any tweaks won't be part of TobEx. They will have to be a completely separate mod.



If this is the way we would like to go forward, this is what I suggest:

The TobEx package will include:
1. the main DLLs
2. a .tpp to INCLUDE as part of your mod
3. some instructions to help with version checking and updating (? still thinking about this part)
4. NO INI FILE - all the 'standard' features of TobEx will always be enabled (this is going to be hell for compatibility, and therefore users CANNOT use incompatible mods, so ditch your own EXE patches)


Tweaks will be a separate 'mod' and will include:
1. an INI file to activate/deactivate tweaks (the DLLs in the TobEx package will have all the coding required for the tweaks, they would just be enabled by this mod)

[Jarno Mikkola]

An analogy: when WEIDU came along, we could as a community have gone for a model where the user has to download WEIDU before running any WEIDU mods. Actually, we just bundle WEIDU up with every mod, and the end user doesn't need to know what WEIDU is.
... thoughts?

Try the BWS, and you never ever need to know what the WeiDU.exe actually really is_{, if you get lucky}... or what a WeiDU mod actually even means.
As you can install a few mods, or 300+ with it. OK so it doesn't have every control unit the WeiDU has in usage... yet, but you have to sacrifice something, and the community decided that to be the simple direction usage on WeiDU.exe with the reward that it's easy to use to make new mods, and on the part of BWS, the sacrifice was the small size and exact user customization(which is being honed as the betas come out), but any given in/out put is at least partially stable.

Edited by Jarno Mikkola, 01 February 2011 - 07:24 AM.

[DavidWallace]

If this is the way we would like to go forward, this is what I suggest:

The TobEx package will include:
1. the main DLLs
2. a .tpp to INCLUDE as part of your mod
3. some instructions to help with version checking and updating (? still thinking about this part)
4. NO INI FILE - all the 'standard' features of TobEx will always be enabled (this is going to be hell for compatibility, and therefore users CANNOT use incompatible mods, so ditch your own EXE patches)


Tweaks will be a separate 'mod' and will include:
1. an INI file to activate/deactivate tweaks (the DLLs in the TobEx package will have all the coding required for the tweaks, they would just be enabled by this mod)

This sounds very much what I had in mind. I'm entirely happy to avoid hacking the EXE in favour of letting ToBEx do it for me (my internal version of SCS already does so if it detects ToBEx). I don't see any particular reason to allow fine-tuning of the core of ToBEx, since it's either bugfixes or things that are invisible in-game until activated.

One thought: on this model, I'd prefer the default option to be that ToBEx runs from the bgmain rather than from ToBExLoader, again in the interest of making it user-transparent. Power users could easily deactivate that mode. Up to you though.

[Ascension64]

I certainly wouldn't want to generate more than a trivial amount of extra work. If there's a smooth way to do auto-updating that Ascension64's happy to support, great. If not, but he doesn't mind me bundling, I can work around (it's easy enough to check via the ToBEx.ini if the version is up-to-date enough to include the components I need, to update if it isn't, and to tolerate intermediate cases as no worse than what would happen on the manual-install scenario). I'm even not-too-bothered about just saying "install ToBEx" in the SCSII installation instructions, provided I can safely tell the user not to worry about configuring it because I can do it for them.

Easy enough. I've just added versioning info to the DLL. That won't help WeiDU, though. So the easy thing is just to put the version number in a text file, and the .tpp will check if its own version is > than the number in the text file. If so, update, if not, skip.

[Wisp]

I don't particularly wish to be difficult, but could this 'standard' ToBEx be limited to things that merely extend the range of functionality, without altering the default behaviour of the game? I.e. the default behaviour would only be altered if the user also installed some mod which takes advantage of this extended functionality.

I think it's a good development to set the more technical stuff apart, to be a resource for modders, as DavidW put it. However, as such, it should simply be a resource for modders, rather than something that also bundles possibly unwelcome tweaks (as should be plain from history, "fix" and "tweak" are not two clearly distinct states). This argument obviously rests squarely on the assumption "resource for modders" is a direction A64 agrees with. But if I haven't already said so (I have, I know) I think that it is both a good direction, and the direction ToBEx should take to be a standard, as opposed to yet another tweak pack.

Obviously the expulsion of some fixes (such as the dispel fix) to ToBEx' other half may be regrettable, but I think it is worth it to have a reasonably clean distinction between the two parts.

[DavidWallace]

I don't particularly wish to be difficult, but could this 'standard' ToBEx be limited to things that merely extend the range of functionality, without altering the default behaviour of the game? I.e. the default behaviour would only be altered if the user also installed some mod which takes advantage of this extended functionality.

I think it's a good development to set the more technical stuff apart, to be a resource for modders, as DavidW put it. However, as such, it should simply be a resource for modders, rather than something that also bundles possibly unwelcome tweaks (as should be plain from history, "fix" and "tweak" are not two clearly distinct states). This argument obviously rests squarely on the assumption "resource for modders" is a direction A64 agrees with. But if I haven't already said so (I have, I know) I think that it is both a good direction, and the direction ToBEx should take to be a standard, as opposed to yet another tweak pack.

Obviously the expulsion of some fixes (such as the dispel fix) to ToBEx' other half may be regrettable, but I think it is worth it to have a reasonably clean distinction between the two parts.

It's going to get in SCS's way not to have (at least) that fix. But I also take the point.

Two suggestions:

1) I think (speaking as a longterm observer of, and occasional participant in, the Fixpack Wars) there are some game-functionality-affecting bits of ToBEx that are totally uncontroversially/unambiguously bugs. For instance, the EquipRanged Action Fix, the AddKit Actions Fix, the Disease/Poison fixes, etc etc. In addition, most of these are much too technical to be left as tweak choices for end users. (If you'd asked me, before I started modding, whether I wanted to install the "Brighten On Disable Brightest No3d Fix", I wouldn't have had a clue what you were talking about, and telling me that it "fixes the behaviour of 'Disable Brighten' in baldur.ini when 3d acceleration is disabled" would not appreciably have helped. I hardly understand it now.)

In fact, the only things I see that even faintly look controversial are the dispel fix, the Cleric-Ranger HLA fix and the Correct Experience Gain fix, all of which are also explicable to end users. (Now, personally I think those are also totally unambiguous bugs, and if Ascension64 wants to treat them that way I'd be fine with it, but they're closer to the sort of things that have provoked panic in the past.)

2) Ascension64's proposal was to distribute ToBEx without an ini file, and then (in effect) distribute an ini file for the residual tweak options as part of a new ToB tweaks mod. As a slight variant, why not distribute the residual-tweak ini file as part of the core install, but with all the options set to zero. That would allow, e.g., SCSII to enable the dispel fix or the stoneskin fix (the latter I don't really care about except for legacy support but the former is quite important) and remains compatible with a ToBEx Tweak mod that gives end users fine control over tweak choices.

[Turambar]

1) I think (speaking as a longterm observer of, and occasional participant in, the Fixpack Wars) there are some game-functionality-affecting bits of ToBEx that are totally uncontroversially/unambiguously bugs. For instance, the EquipRanged Action Fix, the AddKit Actions Fix, the Disease/Poison fixes, etc etc. In addition, most of these are much too technical to be left as tweak choices for end users. (If you'd asked me, before I started modding, whether I wanted to install the "Brighten On Disable Brightest No3d Fix", I wouldn't have had a clue what you were talking about, and telling me that it "fixes the behaviour of 'Disable Brighten' in baldur.ini when 3d acceleration is disabled" would not appreciably have helped. I hardly understand it now.)

I agree with you, that most fixes are too difficult to explain, and should be installed by default, directly in the main component (or, at least, all together in a big 'IE engine fixes' component).
I think this is also the case of all those 'externalize ...' components, which are usually only needed by other mods, but have absolutely no visible effect on their own; I think there could be a generic component with all of them, which is suggested for whoever wants to install extra mods which require them (such as some of my tweaks).
You could, then, leave separated those components which have themselves, on their own, an immediate effect on the game, so that each player can personally chose if they want them (for example, I think these belong to this last category:

• Allow Equipping Armor in Combat
  
• Assassin and Bounty Hunter Penalty to Similar Kits
  
• Disable Force Inventory Pause)

Edited by Turambar, 01 February 2011 - 07:13 AM.

[DavidWallace]

Those examples are in Ascension64's own Tweaks category - don't worry, no-one's suggesting installing them by default. I think Wisp's concern is with components in Ascension64's Fix category that nonetheless affect the game, and my response is that (at least) almost all of those should be in a core install, because they're unambiguously very-technical bugfixes.

[cmorgan]

I applaud the idea; I just need to get my head around what this means.

When I mod Oblivion, I set up OBSE, I use mods that are compatible, and I play from the OBSE loader.

Under this similar idea, a best case scenario;

1. The user would download a weidu packaged mod (this would now include ToBEX, with all basic "fixes" enabled by the .dll automatically, and a zeroed out .ini).
2. When I as a modder set up the mod, the first check would be to see if ToBEX already existed, and if not, my mod would install it.
3. If I (for example) wanted to extend the songlist.2da limit, I would check the tobex.ini to see if it was enabled. If not, I would change it to be enabled. (Unless of course this is actually classed as a "fix", which I think is as important a "fix' as allowing support for spellbooks and scrolling kit screens, etc. - but I am just using this to think through the challenges).
4. The mod would install as usual, and the only thing I would need to do is make sure the Mac OS detection skipped the song extensions and warn in the readme.
5. The user would start the game directly from BGMAIN.exe or from the regular shortcut, and either eway ToBEX would hijack the startup and run.


challenges - compatibility on things more controversial than songlist limits - what happens when two mods have directly conflicting .ini requirements - how do you warn someone that they are about to create bugreports because the last mod installed unset a needed .ini setting?

[DavidWallace]

@cmorgan: yes, that's the idea.

Regarding compatibility: the intention, as I understand it, is that the core contains anything that increases functionality without itself changing the game experience (e.g., the extended songlist), as well as bugfixes (modulo Wisp's concern about one or two of them). So I don't think in practice there's much compatibility danger. This dovetails quite nicely with Ascension64's feeling (on a different thread) that ToBEx stability would be improved by reducing customizability a bit. (Obviously, actual tweaks more-or-less have to stay customizable.)

I also would envisage very few mods that would actually play with the ini settings that control the tweak components: Any ToBEx tweak mod obviously would; and perhaps Fixpack; and perhaps a few bits of SCS and SR depending on whether the Dispel fix makes it in, but not many more.

Edited by DavidWallace, 01 February 2011 - 08:46 AM.

[Jarno Mikkola]

Those examples are in Ascension64's own Tweaks category - don't worry, no-one's suggesting installing them by default. I think Wisp's concern is with components in Ascension64's Fix category that nonetheless affect the game, and my response is that (at least) almost all of those should be in a core install, because they're unambiguously very-technical bugfixes.

So what you are really after is a build model that would allow you to assume that if the 'fix' component is installed, all the individual fixes are enabled without the user needing to enable them from from anywhere, they could go and disable them if they wanted in case it bugs out the whole game, but you wouldn't need to worry about those cause mods build wouldn't need to count for those... right ?
So if it's installed, it's enabled by default. And if the player then goes and disables it and gains advantage, it's their business !

[Wisp]

1) I think (speaking as a longterm observer of, and occasional participant in, the Fixpack Wars) there are some game-functionality-affecting bits of ToBEx that are totally uncontroversially/unambiguously bugs. For instance, the EquipRanged Action Fix, the AddKit Actions Fix, the Disease/Poison fixes, etc etc. In addition, most of these are much too technical to be left as tweak choices for end users. (If you'd asked me, before I started modding, whether I wanted to install the "Brighten On Disable Brightest No3d Fix", I wouldn't have had a clue what you were talking about, and telling me that it "fixes the behaviour of 'Disable Brighten' in baldur.ini when 3d acceleration is disabled" would not appreciably have helped. I hardly understand it now.)

In fact, the only things I see that even faintly look controversial are the dispel fix, the Cleric-Ranger HLA fix and the Correct Experience Gain fix, all of which are also explicable to end users. (Now, personally I think those are also totally unambiguous bugs, and if Ascension64 wants to treat them that way I'd be fine with it, but they're closer to the sort of things that have provoked panic in the past.)

Ultimately you are probably right that fixes will be included. Looking over the list it seems most of the current components are of the fix/tweak kind, so keeping them optional obviously won't work if A64 wants to reduce the number of possible configurations of ToBEx. I'd like to think we're past serious 'fix vs. tweak' arguments, but obviously everyone won't agree on everything and there'll be people who don't want X. But as you say, it's A64's mod and his call and most of the fixes probably are uncontroversial (even if it's because the user doesn't know what he's getting ).

[the bigg]

I'd like to think we're past serious 'fix vs. tweak' arguments

Has there ever been a serious 'fix vs. tweak' debate outside of certain places? More importantly, should we even care about such semantics? If we let these semantics in, certain people will code certain mods so that they rely on the vanilla version of AddKit (or otherwise rely on vanilla bugs), and then claim that 'AddKit Action Fix' is an Hidden Bug because it causes their mod to misbehave. It's far better to flip the bird at those people and use common sense to decide what changes the game enough to warrant being optional and what does not.

Edited by the bigg, 01 February 2011 - 09:15 AM.