[Jimmie Allen]

I'm so very, very bad at this whole "not getting too far into it" thing.

Progress will be laughably obsolete by the end of the weekend.

[LuCY sCoTT]

tease

[Elizabeth Davis]

How's this for tease?

After a full day's labor, Fundament.esm is somewhere between 25% and 50% done. (Depends entirely on how sneaky the bugs are...)

Like Progress, it will allow the user to easily configure skill use values and GMSTs. Unlike Progress, that means every numerical GMST. Even non-Vanilla ones, like for JRoush's AVUncapper. Also numerical Oblivion.ini settings. And it keeps track of what all of these were before they were edited, and sets them back to their original values between save loads, and before quitting the game. No persistence of edits across game loads, and Oblivion.ini changes made through Fundament are not saved to the actual file.

Nothing is set to zero (or anything else) before initialization. That's for two reasons. First, initialization is instantaneous -- the five-second delay has been conquered. (Well, at worst it's been moved to the pre-game menu. I put an initialization message there, just in case.) Second, I've stolen TheNiceOne's brilliant SetQS-based scheme from HUD Status Bars. This means that .ini files only have to contain settings that you WANT to change... not every single setting you COULD change. One of the ini-file functions is to load another ini-file, so you can split up your configuration in whatever way is sensible to you.

Fundament greatly expands on Progress's "compatibility platform" function. For starters, other mods (even non-dependent ones) can use Fundament's ini-loading system to record any scripted changes they make. Beyond that, where Progress was basically a scrap of notebook paper that slaved mods could peek at and scribble on, Fundament comes with a clean API consisting of a few dozen user functions which allow mods to assert base values (with a priority system allowing one mod to yield to others, or forcefully assert itself); set multipliers on those base values; get the current official values (before and after multiplication); and if they really want, get a full list of everything any mod is doing with a given skill, GMST or ini setting.

Last but not least, does anyone remember Formulator? Merged. (And actually works, though no OBME support for now.)

Incidentally, I'm knuckling down to standards: .ini files will be loaded from Data\ini\, with no support for other locations. However, it will support character-specific .ini files like recent versions of my other mods. This time around, instead of searching for "Fundament - CharName.ini", I'm changing the scheme to look in Data\ini\CharName\Fundament.ini so that one character's overrides are all grouped together. Fundament's load-config function is generic and can be used by other mods, and this character-override scheme is part of the deal. Going forward, most of my mods will take advantage of this, and I hope other mod authors use it as well!

[Stephanie Valentine]

errr ok ...I kinda followed that, but what would all that be used for besides things like what nGCD and Progress already do?

Is this more for other modders to latch onto or will this be for a mod with a specific scope you are working on?

[Stephani Silva]

A little of each, really. Relative to Progress, the user-side improvements are mostly polish and stability stuff... eliminating all the odd little caveats and work-arounds and "don't do this" and "wait for that." And yeah, I do understand that for someone who's been used to all that for years, it might not seem particularly meaningful. But I still see new faces around here every time I look at the forum index. Just because we had to suffer, doesn't mean they should too.

And yeah, I'm definitely hoping other modders latch on. Under the hood, I think this is one hell of a tool. Cobl has some compatibility-oriented features for scripters that were a good idea but never widely used... but the difference between that and this is essentially the difference between vanilla Oblivion and OBSE v0020. Here, the compatibility features aren't something you spend extra effort to use; they're integrated with functions that will save coding time and make your mod more stable and user-friendly. On top of that, Progress is pretty much ubiquitous already so you don't have to worry about convincing users to install it as a prerequisite.

Nehrim-compatible, too!

[Haley Merkley]

Code finished, all features tested. Need to make default config files and write documentation, then clean the WIP stuff out of Formulator and merge it in.

Might be tomorrow, though. 12 straight hours is a bit much already...

[Queen Bitch]

Well, get on with it then.
We're waiting.

[R.I.P]

Bah! I've frittered the hours away with such trifles as forum debates and fiancee-entertainment. And I forgot that I should probably update the Progress submodules, since they're completely incompatible with the new architecture.

In other words, Another Deadline Missed. But, soon!

[Sarah Unwin]

Losing hours of work to a CTD does terrible things to the mood.

[Nina Mccormick]

Losing hours of work to a CTD does terrible things to the mood.

Yuck.

[Bek Rideout]

I said the end of the weekend. I just didn't say which weekend.

Seriously though, work continues apace, there just turned out (as usual) to be more to do than I expected. This is mostly because I'm not reusing nearly as much of my old code as I should (which is to say, I'm going over ~200Kb worth of scripts with a fine-tooth comb and rewriting half of them from scratch). I've also decided to expand Formulator to cover several more form types; basically, anything enchantable. (Actually I decided to do that a long time ago. I thought I'd already done it. D'oh...)

In the interest of continued teasing, though...

; =============; Fundament.ini; =============; Global and character-specific copies of this file are loaded when Fundament; initializes. The global file is loaded first, allowing the character-specific; file to contain overrides. Global configuration is located in Data\ini\.; Character-specific configuration is located in a subdirectory with your; character's name. For instance, Bendu Olo's configuration files are found in; Data\ini\Bendu Olo\. Nothing bad happens if either file is missing.;; You can do a lot of things here, but none of them are mandatory.;; The Basics; ----------; At the most basic level, you can change GMSTs, Oblivion.ini settings and; skill advancement rates. You can also directly load another configuration; file, which has access to all the same functions.;; Fundament.ini operations consist of setting a few quest variables, then; triggering a stage script which processes them. The first step is to set one; of four variables to the name of the thing you want to operate on. If more; than one of these variables contains a non-empty string, the operation will; be skipped.;; To change the value of the game setting iTrainingCostMult -;   set fd.GMST to sv_Construct "iTrainingCostMult";; To change the setting "fGamma" in the "Display" section of Oblivion.ini -;   set fd.Ini to sv_Construct "fGamma:Display";; To change the advancement ("use") rate for the Acrobatics skill -;   set fd.Use to sv_Construct "Acrobatics";; To load global AND character-specific copies of "Awesome.ini" -;   set fd.File to sv_Construct "Awesome";; For every operation except File, you also need to set a value. (If you don't,; it defaults to zero.) -;   set fd.Value to 3.14159; ; Finally, each skill actually has two separate use rate settings which apply; to different uses of the skill. They're numbered 0 and 1, and use rate 0 is; configured by default. If you want to configure use rate 1 instead:;   set fd.Which to 1;; Once you've set up an operation, this command executes it:;   SetStage fd 1;; All variables are then reset, and you can perform another operation.;;; ==============; Advanced Usage; ==============;; Assertions; ----------; The instructions above are enough to handle most situations, but internally; Fundament is doing much more than just setting values. When you perform one; of the operations above, you're actually creating an "assertion" which is; recorded with a tag (by default, the base name of the file it came from) and; a priority (default 0). One use rate, GMST or ini setting can have any number; of assertions, but each tag is unique; if a new assertion is received with; the same tag as an existing one, the old one is replaced. To determine the; "canonical" value of a setting, Fundament runs through the list and picks; the assertion with the highest priority. If two or more are tied, the most; recent one is used.;; It might seem like overkill, but other mods can make assertions in their; scripts, either by being dependent on Fundament and calling its internal; functions, or through this same configuration system using RunScriptLine; commands. Other mods also have access to Fundament's records about what each; setting should be. This allows situational changes to be made during gameplay; without causing confusion about the base value of a setting. This facilitates; compatibility and eliminates potential bugs.;; Multipliers; -----------; In addition to assertions, Fundament keeps a list of multipliers for each; setting. These are also tagged, but have no priority. When determining a; setting's canonical value, every multiplier is applied to the leading; assertion.;; Configuration Switches; ----------------------; By setting additional variables, most features of the Fundament API can be; accessed within the configuration system.;; To set a multiplier instead of making an assertion -; set fd.Mult to 1;; To remove an assertion with the current tag (see below for changing tags) -; set fd.Rem to 1;; To update Fundament's records without actually setting the value in-game; (outside of user configuration, this is usually preferred) -; set fd.DoNotAssert to 1;; The flags above work together in any combination. For instance, setting Mult; and Rem will remove a multiplier. There is one other flag which works only in; specific combinations.;; To place the current canonical value of a setting in fd.Value:; set fd.Get to 1;; To place the current leading assertion for a setting into fd.Value:; set fd.Get to -1;; To place the current total multiplier for a setting into fd.Value:; set fd.Get to -1; set fd.Mult to 1;; If fd.Get is non-zero, the Rem and DoNotAssert flags are meaningless. The; Mult flag is only checked if fd.Get is negative.;; Changing Tag & Priority; -----------------------; Whenever the config loader starts to process a file, it sets the values of; fd.Tag and fd.Priority. The tag is set to the file's base name (e.g. for; Fundament.ini, the tag is "Fundament") and the priority is set to zero.; These can be changed by setting them directly, but unlike other config values; they are NOT reset after each operation. Any change will persist until the; end of the file. This is true even if you use the File operation to load; another config file: the current tag and priority are stored, defaults are; set for the new file, and after it finishes the original file's context is; restored before continuing.;; To change the tag for subsequent operations in this file:; set fd.Tag to sv_Construct "New Tag";; To change the priority for subsequent operations in this file:; set fd.Priority to 1.61803;; Note: negative priorities are invalid, and assertions made with a negative; priority are discarded. Likewise, an empty string is not a valid tag.;; External Operations; -------------------; A series of RunScriptLine commands can set up and perform any Fundament; config operation. (Otherwise the Get flag would be mostly useless!) When; interfacing with Fundament in this way, it is essential to explicitly set; fd.Tag and fd.Priority while preparing your operation, and always set up and; perform an operation within a single script frame.;; Debug/Message Options; ---------------------; NOTE: If you want debug output for the configuration process, these settings; should be moved to the top of the file. If you don't need it until the game; is running, they can be left at the end.;; Various messages can be sent to the console, to ConScribe (Fundament.log),; and to obse.log. For each you set a threshold, and any messages with a debug; level BELOW that threshold will be sent there. Messages with a debug level of; at least 1 are prefixed with "Fundament:" and the tag for their debug level.; (Messages sent to ConScribe have only the level-specific prefix.);; Debug levels are:; -1 = "New Game" and "Game Loaded" notifications. More useful than you think!;  0 = Notifies when a configuration file is loaded through Fundament.;  1 = "ERROR" - notifies when function calls fail to complete.;  2 = "DEBUG" - gives various messages tracking internal calculations.;  3 = "TRACE" - shows entry and exit for most function calls.;  4 = "VERBOSE" - additional tracking messages inside loops.;; The settings and their defaults are:; set fd.debug to 0; set fd.debugConScribe to 0; set fd.DebugOBSE to -1

[Emzy Baby!]

Hey, your not thinking of replacing Progress with this are you?
My load order isn't going to look right without it and the associated additional plug-ins. but

[Hilm Music]

I wonder if Fundament will allow me to track down which mod/s are changing GMST without me knowing (I have a little problem with iActorLuckSkillBase). I suppose those mods and modders would have to acknowledge Fundament first, but lets hope it catches on among the OBSE modders, it really looks as powerful as awesome.

I saw a post where you mentioned bundling all your 80 detect life shaders into one file, changing the shader to be played through OBSE 21 functions... I have an experimental mod which uses the Supreme Magicka method of making the LifeDetect shader invisible and playing a different shader on the actor (so you can have one for the living, one for undead, for daedra, etc...). I did bundle in all your 80 shaders and a few more, organizing them in an array, to be picked and played by a token on the actor as per definitions in an .ini. I also added Detect Enchantment and Key effects through OBME, although they might be too little for what the OBME requirement should provide.
I see your current modding projects are a few orders of magnitude above this in complexity, and maybe you do fine with just one shader for all actors, but still, does it sound interesting to you?

[April D. F]

Hey, your not thinking of replacing Progress with this are you?
My load order isn't going to look right without it and the associated additional plug-ins. but

What, have you just been skimming? Yes, this supersedes Progress, and blows it out of the water in every regard except maybe the sheer simplicity of Progress.ini. That's a deliberate trade-off for safety (you have to TRY to break your game with Fundament, rather than merely put your .ini in the wrong place) and, obviously, extreme flexibility in what you do and don't configure. Unless told otherwise, Fundament doesn't overwrite other mods' settings like Progress did so users who only download this because another mod requires it don't have to worry about configuration.

The design of the bundled mods is also being revised with an eye to maximally user-friendly configuration. For instance, GSD is now Global Rate Control, which lets you set a base multiplier (slowdown optional). This isn't a simple fSkillUseMult edit, it's a multiplier on whatever is already in place. So if you've got an already-modded game and you have a good feel for how you want to slow it down (or speed it up), you don't have to first research and review your current settings... you just set the multiplier and it goes. (It also does the same thing for training cost.)

I'm planning to spend a lot of time building default/sample config files that will hopefully be even easier for the layman to use than Progress's. One of the key concepts throughout the configuration system is "if you don't want to change it, just don't set it." Everything is reset to defaults before configuration is loaded, so settings don't carry over between sessions; and with the ability to load any arbitrary configuration file through Fundament.ini, you can group your settings in whatever way is meaningful to you, and enable/disable arbitrary groups of them just by deciding which files to load. Likewise for the supplied defaults, you just put in a load operation for the ones you want, rather than having to rename and replace the main file like with Progress.

And I think it's worth stressing that other mods can take full advantage of Fundament's config-loading system, whether to assert a couple of GMSTs that are essential to them just for compatibility's sake (e.g. nGCD disables vanilla magicka regen), or as a complete initialization package -- you can still set quest variables the old fashioned batch-script way, and nothing says they have to belong to Fundament!

I wonder if Fundament will allow me to track down which mod/s are changing GMST without me knowing (I have a little problem with iActorLuckSkillBase). I suppose those mods and modders would have to acknowledge Fundament first, but lets hope it catches on among the OBSE modders, it really looks as powerful as awesome.

find /i "iactorluckskillbase" *.es? > output.txt
(This'll take a minute or so, if you don't think it's happening in an ESM change the '?' to a 'p' to avoid slogging through Oblivion.esm.)

Random Detect Life shader? That does sound pretty neat! Not quite what I talking about with the OBSE request, though... the goal there is to not even need an array full of 80 shaders, instead being able to pick the desired settings (or create random ones) on the fly. This would wind up becoming a Formulator function.

[lucile]

Well I have a question about Progress. Tejon - I know you're busy, so if anyone has the answer I'd appreciate it.

I'm using Progress and the new Realistic Leveling that just was released (as an esm). I'm getting fluctuations in my level. The new character is still level 1 (when not fluctuating). I checked the ini for both mods and I'm not seeing the fSkillUseFactor active in both. In Realistic Leveling it is commented out. Are there any other settings that may be conflicting to cause this.

If I open the character inventory/map/stats thing then it readjusts, but also when entering a new dungeon it goes back to being off again. I know stealth is a shortcoming and I am using SDR.

I just want to make sure there is nothing else I need to be checking cross mod wise.

thanks

[Leonie Connor]

None of my mods affect level at all (other than nGCD, but you're obviously not using that), so either the Realistic Leveling calculations are getting confused somehow, or something else is in play. I don't think this can be related to Progress, though. Neither the fSkill*** settings nor the individual skill advancement rates will affect your current skills when changed, they only affect the skill experience required to advance. (If reduced, they can cause instant advancement; but not until you actually use the skill, and you'd get the normal message and drumroll.)

I can only think of two things of mine that might contribute: Anyclass and Skill Decay. If this is happening at level 1, Skill Decay is probably not a factor. Anyclass might have odd effects if the Realistic Leveling script makes certain assumptions, so if you're using it, ask ABO if he thinks it could be a factor.

Outside of my own stuff, the only mod that immediately springs to mind as a potential culprit is Dynamic Place-Centric Scaling, which edits your level to control the results of leveled lists. It's known to need compatibility patches for most character leveling mods. (Simple edit, the other mod just has to edit a DPCS quest variable instead of setting level directly.)

[marie breen]

Actually I am using The Versatile Adventurer (Any Class).

Which makes the highest seven your class.

Maybe RL is having issues with those changing?

If it does - I guess I should ask ahead - will nGCD be fine with it?

[Jinx Sykes]

nGCD is fine with it. I can't think of many reasons RL wouldn't be, except for extremely aggressive optimization. If that's the problem it should be a pretty simple fix for ABO.

[Destinyscharm]

Ah, documentation, my ancient nemesis. Have at thee!

Feature set nailed down for bundled mods (MBSP, etc.), though not yet implemented. I wrote all the .ini files first, fully describing the options, and now comes the far more enjoyable bit where I figure out how to make it all work. Most of the core formulas will be copy-paste from the Progress versions, but a lot of the old active scripts can now be replaced with triggered events, which is better in numerous ways. A few new options here and there, too.

[DAVId Bryant]

Right, so I've found the cause of nGCD reading penalties as bonuses. It's because I changed techniques from reading the value from the spell, to reading the actual value applied to the player... and where a spell's magnitude is always positive so I had to specifically subtract the penalties, an active effect value that represents a penalty is already negative. When I subtracted it, the obvious thing happened.

Anyway, a couple of new OBSE commands have made the script about as compact as it can possibly be, and I've incorporated it with Fundament so that no matter how many mods need that data, the loop only has to run once each frame. (Also so that the code never has to be written again!) Next version of nGCD will depend on that.

But for the moment, if you know how to launch the CS with OBSE, you can fix it by finding the script nGCDfnGetAbilities and completely replacing it with this:

Spoiler

ScN nGCDfnGetAbilitiesarray_var AVint indexarray_var eachbegin _Function {AV}	while (index < 33)		let AV[index]["Mod"] := 0		let index += 1	Loop	foreach each <- GetActiveEffectCodes		if eval !(IsNthActiveEffectApplied each["key"])			CONTINUE		endif		if eval !((GetSpellType (GetNthAEMagicItem each["key"])) == 4)			CONTINUE		endif		let index := GetNthAEAV each["key"]		if eval !(index)			if eval !(MagicEffectUsesAttribute each["value"])				CONTINUE			endif		elseif (index > 32) || (index == 11)			CONTINUE		endif		let AV[index]["Mod"] += GetNthAEMagnitude each["key"]	Loopend

[Chenae Butler]

My whole (almost finished) installation came to halt since a few days, while I′m eaglerly awaiting news about your new mod. Tried other leveling mods, but apparently it has to be nGCD+Progress for me,or its successor. So first of all, thank you for providing help with the old nGCD as well!

So, I′ve loaded nGCD together with OBSE in the CS (via WryeBash Launcher) and replaced the script. But since I don′t know how to script, I′ve got a question: You wrote to completely replace the old script. Up to that last "Loop" it′s clear, but in the original script there′s five more lines at the bottom; four of them are commented out, and I guess that means they have nothing to do with the actual script. But the first of those five is "end" - do I leave that "end" in the script, or should the last word be "Loop"? And is it correct that it′s fine to leave out the other four lines (something like for example: ; )?

Apart from that (I′ve left all five lines, including that "end" in the script for now), when I save the script, there′s the message: "Script ′nGCDfnGetAbilities′, line 27: More args provided than expected by function or command". Is it okay to just continue, or is this to be regarded as error message?

Thanks for still supporting your work!

[Danial Zachery]

There's an "end" in the quoted script above. Maybe you didn't get the whole thing? In the CS, you should be able to select the whole script with Ctrl-A, then hit backspace to clear it. Paste in the entire script above, including the script name and variables.

The commented lines at the bottom are from another plugin, Construction Set Extender. They don't do anything important and can be safely deleted.

That error is a critical failure, but it's not happening for me and I just double-checked that there are no errors in the script I posted... if it doesn't work when you paste it in again, let me know.

[Penny Courture]

There's an "end" in the quoted script above. Maybe you didn't get the whole thing? In the CS, you should be able to select the whole script with Ctrl-A, then hit backspace to clear it. Paste in the entire script above, including the script name and variables.

The commented lines at the bottom are from another plugin, Construction Set Extender. They don't do anything important and can be safely deleted.

That error is a critical failure, but it's not happening for me and I just double-checked that there are no errors in the script I posted... if it doesn't work when you paste it in again, let me know.

Duh, great start to miss the "end" (hm, would that be a pun in English?...), and then, since copy-paste with right mouse click didn′t work, I didn′t think about Ctrl-C and Ctrl-V, and wrote it manually. Maybe not the best idea if you don′t have a clue of WHAT you are writing...
Anyway, I′ve replaced the whole thing now (copied it), saving worked, and now I′m veeery curious whether the Bathing mod (the only problem I′ve encountered so far using nGCD, see a few posts above) is working as intended now. I′ll let you know within the next few hours if it works (albeit I′m not so sure if I′d be able to surprise you with whatever result I come up with ). The other thing is that I′m a little unsure about those oldish mods like Bathing mod, reading about all those Do′s and Don′ts of mods using MODAV, MODAV2, MODWhatEver, and how they could mess up the game without necessarily being recognized by the unknowing user...but that′s just a side note.

However, now since I already catched you online, a few questions about nGCD-settings if you wouldn′t mind. Basically, I′m using AVUncap and the JCN_AVUncap-plugin, and like to have skills capped at or around 200, BUT attributes around 100 plus racial boni, buffs,... I plan to use Progress for skill slowdown and GSD, and don′t want to expect to reach level 50 or more than 2 or 3 skills beyond 100 or 120 within the next few hundred hours, but likewise I don′t want to start with attribute values as low as around 20... And I wonder whether (for example) the Duke Patrick combat mods make any use for combat skills beyond 100, anyway (seems to be best around 50-75?!?)

So, I′d choose the following settings:

.bSimpleUncap to 0
.iLevelMode to 0
.bLevelCannotDecrease to 0
.iTrainingMode to 0 (or -1, don′t know yet, shouldn′t matter here)
.iLuckMode to 0
----------------
.iClassAttr to 5
.iLevelCap to 85 (unsure: is there any point having this any higher? Is there any overhaul - I′m using FCOM this time - making use of a level well over around 60?...)
.iSkillMax to 200
.iAttrMax to 100
.iAttrCap to 200
.bSkillMaxIgnoresAbilities to 1
.bAttrMaxIgnoresAbilities to 1
.iRacialAttributesOffset to 0
.iAttrMin to -1 (I′m also using bgBalancing, where some attributes start as low as 25)
.bAttrMinRaisesAttrMax to 1
.iRacialAttributesBaseValue to 40
-------------------

For Progress I′d choose 4x slowdown, plus GSD with .iRangeCeiling upped to 4200 und .iSkillMax to 200). The other Progress parts shouldn′t matter here...


1.) Would I get anything like the behaviour described above with those settings?

2.) Does it make sense to use .iAttrMin to -1 when using mods that change the starting value of attributes, like bgBalancing?
And as related question:
3.) Any practical reason to raise .iLevelCap over 85? I mean, is there any mod that make any use of a char level beyond, say, 60 (save from DLL maybe)? (As a note, I′m currently using FCOM.) Or has that setting more to do with tuning the starting attribute values ? These I don′t want to have too low, one reason why I want attributes capped around 100 and why I′m not using SimpleUncap = 1... But regarding that whole complex I′m still a little unsure. What′d you (or any experienced nGCD/Progress-user) say?

Thanks very much for help!

[Andrea P]

Duh, great start to miss the "end" (hm, would that be a pun in English?...), and then, since copy-paste with right mouse click didn′t work, I didn′t think about Ctrl-C and Ctrl-V, and wrote it manually. Maybe not the best idea if you don′t have a clue of WHAT you are writing...

This triggered an actual "eyes widening in horror" moment for me. Oh, you poor, poor soul...

tejon, I'm guessing "not even a little bit", but are you still interested in TABOO?

[Daramis McGee]

@Cherisu:
Since you want a high skill cap, you should raise the level cap. The reason is, nGCD bases skills-per-level on SkillMax / LevelCap. With level cap at 85 and skill max at 200, you'd need about 45 skill increases per level! Setting level cap to 185 makes 21 increases per level, which IMO is perfect. (Remember that's all skills, not just majors.)

Other than that, I think your settings look like they'll do what you want! I just discovered another bug while checking them out, but it won't affect your configuration.

And yes, AttrMin = -1 will work fine with Race Balancing Project.

tejon, I'm guessing "not even a little bit", but are you still interested in TABOO?

As much as ever! I'm just terribly wary of the fact that it will steal all my time, and give me no money in return.