We all know I'm the ultimate master of that art...

I'm having an issue with the SetCellWaterHeight command.

Here is the code:

	if (arg3.ParentCellHasWater == 0)		set doorparentcell to arg3.GetParentCell		SetCellWaterHeight doorparentcell finalwaterheight		SetCellHasWater doorparentcell 1		Print "Interior Cell Water Height: " + $finalwaterheight		PurgeCellBuffers	endif

The finalwaterheight comes out as -630 (close enough), but the actual water height ends up being 0. Any idea what may be causing this discrepancy?

Do SetCellHasWater before SetCellWaterHeight. Cells without water can't have their water height set. It might make more sense for SetCellWaterHeight to do this internally if the cell doesn't have water.

The docs for GetNthEffectItem say that the School value returned for script effects is an AV code. Is this correct? It's not the 0-5 school code used by GetSpellSchool?

Also, we discussed this early on but it's been a while and I just realized never verified it: properties that are not defined for a given effect are absent from the StringMap (the key does not exist), rather than being present with a zero or null value, right? This is necessary for the keys OBME will be adding, and while it might work either way for the vanilla keys, consistency is good.

Edit: don't see anything in the notes, did the case-sensitivity issues with ModAVMod[C] get resolved?

Edit more: Uh-oh, I think I've found a very old bug. TriggerPlayerSkillUse and IncrementPlayerSkillUse do not adjust the amount of use granted based on whether the skill is minor/major/specialization. UESP's http://www.uesp.net/wiki/Oblivion:Increasing_Skills seems to indicate that it's the amount of experience required that changes, not the amount granted per use; but GetRequiredSkillExp reports the same amount for any skill at a given rank, and some comparison testing seems to show that it's correct and Trigger/Increment should be adjusted. I sincerely doubt any mod using these commands actually intends the current behavior, since we've all been working from the same wrong information.

And, last but not least: if an event handler only has one parameter, can you still use a script which accepts two? More specifically, can I register the same script to both OnSkillUp and OnScriptedSkillUp?

Yet more last but still less least: GetRequiredSkillExpC would be handy.

I tried that - still the same result. I even instituted a "ticker" system that waited a few frames between the SetCellHasWater and the SetCcllWaterHeight calls, but neither made a difference as far as I could tell.

Edit: I added in a check like so:

			if (SetCellWaterHeight doorparentcell finalwaterheight == 0)				set ticker to 2				Print "Interior Cell Water Height: " + $finalwaterheight				return			endif

And as you can likely guess, it kept looping and spitting out the Print message in the console. Also, in case it matters, I'm calling this function on an unloaded (I believe) interior cell.

Edit: I also checked to make sure that the doorparentcell ref was valid - it matches the CS FormID for AnvilMorvaynsPeacemakers.

Thanks for catching that. It is in the range 0-5. Is that preferable or would you rather have it return an AV code? Either way produces confusion; since it's your request I'll let it be your call.

Yes. Only the SEFF stringmap and the ActorValue field are optional, the others are defined for all effect items.

Well it wouldn't be a proper release if we didn't forget *something*. On it.
EDIT: I'm not seeing this behavior. PM'ed.

Yes, the skill exp is fixed and the skill use gets multiplied by the specialization/major factor. I agree that's probably not what's intended/expected by existing mods using those cmds, but still I'm not sure we want to modify them (they've been in use for quite a while). I can hook up a new pair of commands which would call into game code and get the modifiers applied.

At present, no - the number and types of the parameters must exactly match those expected for the event. I guess for now you would want to have your OnSkillUp handler call your OnScriptedSkillUp handler with a second parameter of 1.

I was kinda hoping we'd see the death of redundant 'C' versions of commands with this release:

int avCodestring_var avStringbegin _gameMode  let avCode := 19  let avString := "restoration" ; the following all do the same thing  GetRequiredSkillExp avCode  GetRequiredSkillExp avString  GetRequiredSkillExp "restoration"end

But it's trivial to add if you still want it.

Ah - yeah, it looks like SetCellWaterHeight was set up to only operate on interior cells that already have water. Updated to work with cells that don't have water; this also means you don't need to call SetCellHasWater in conjunction with SetCellWaterHeight.

I think everyone who knows the phrase "when it's done" has quite some experience in it.


Didn't IncrementPlayerSkillUse call the game code, when using a positive count number, but using your "formula" (the same ModSkillExp always uses, hence not influencing the PCMajorSkillUps/PCAttributeBonus counter) when using negative counts?
Been a while since I had time, therefore I don't remember that much details.



:intergalactic:

When I add the underscore to the block name, the compiler gives me an error on MyRef.Getpos X and MyRef.SetPos X 999. It says: "Invalid expression for parameter 1. Expected Axis"

I am ignoring the unquoted argument error for the session, so I guess it is interpreting the X as a string.

Can I see the full script please?

There's an issue with GetRaceVoice. It currently only seems to work for races which use the voice of another race. In other words, races using their own voice (High Elf, Imperial, Nord, etc.) don't return anything, while races like Wood Elf and Dark Elf (returns High Elf) and Orc (returns Nord) are fine.

I guess it depends on your interpretation of what the command's supposed to do. From the game's perspective the "race voice" is a race different from the actual race; races that use their own voice don't have a "race voice." From a modder's perspective it probably makes more sense for it to return the actual race if no "race voice" exists. Happy to modify it if that'll work better for you.

Ooops.
It is a very large test script. While trying to strip it down, I noticed I had a float named X. So I guess the compiler is, correctly, trying to use the contents of the X var as the axis.

But I got another one (again, when using the underscore): compiler error when I use sv_construct with a string_var or reference. The first three lines (using a short, float and array element) compile OK..

Error msg: "Invalid expression for parameter 2. Expected Variable" + "Could not parse this line"

scn aaqqxxTestSCRIPTshort ifloat vstring_var s1string_var s2ref reffarray_var arrbegin _gamemode	let s2 := sv_construct "Selected  %g" i	let s2 := sv_construct "Selected  %g" v	let s2 := sv_construct "Selected  %g" arr[1]	let s2 := sv_construct "Selected  %z" s1    ;<<												

That would be much appreciated. Thanks!

I thought it might be a variable name. Putting quotes around the "X" will resolve the ambiguity.

Yeah, format string expects floats for all arguments. You can get away with passing string and ref vars with the default compiler because it doesn't type check. When you're using the override you're better off using string operators. instead of format strings (e.g. simply let s2 := "Selected " + s1). You can combine format strings and string expressions if you want/prefer to use format strings (e.g. for formatting numeric values):

let s2 := sv_Construct "Selected %.2f " + s1, i

Ok done.

Oh, I see. thanks.

Just wanted to say thanks for SetCreatureSkill (which was requested by me). Very much appreciated, just like everything done by the OBSE team of course :bowdown:.

I should note there was a bug in GetCreatureSkill - apparently present since that command's introduction - which caused it to always return the stealth skill regardless of the skill requested. I guess no one has really used it or this would have been noticed, but it's fixed now.

Wouldn't that be?

let s2 := sv_Construct "Selected %.2f " i + s1

Entirely up to you, but in the above case you need parentheses.

let s2 := (sv_Construct "Selected %.2f " i) + s1

That calls sv_construct and then appends s1 to the returned string. Without parens it will try to add i to s1.
The code I posted creates a format string by appending s1 and passes that to sv_Construct.
They both accomplish the same thing.

Yes but in your first example the parameter for the %.2f (which is probably i) came after + s1.... :huh:

[edit]
Or can format parameters be placed at the end of a line inside override blocks? Regardless of where and when the format specifier was used in the line?
[/edit]

I should be more clear about what the override does: it lets you use any arbitrary expression for any argument.
The first argument to sv_Construct is a string. So you can use any expression evaluating to a string for that argument. In this case "Selected %.2f " + s1 is an expression evaluating to a string, so that's the first argument to sv_Construct.
Similarly, since the second argument is a float, you can use any expression evaluating to a float, e.g.:

sv_Construct "Selected %.2f" + s1, someArray[index + 5] - (cos theta) * Call SomeFunction arg1 arg2

Note above that the parens are required around the cos command and its arguments as otherwise we'd have no way of knowing that you don't want the cosine of (theta times the function call result), which would also be a valid but semantically incorrect expression. Languages like C have parentheses around function arguments for this reason; OBSE has them around the function call as a whole for the same reason.

I get what you're saying, but the order of operations there surprises me. If I saw cos theta * Call SomeFunction arg1 arg2, I would assume the default to be (cos theta) * Call SomeFunction arg1 arg2 rather than cos (theta * Call SomeFunction arg1 arg2). Left-to-right reading and all that.

Probably because you're accustomed to C-like languages. Lisp programmers would probably find it pretty familiar. Bethesda's script language doesn't use parentheses or commas or anything other than whitespace to delineate function arguments, and it doesn't need to. There was some discussion back around 0017 about having OBSE require C-like syntax for function calls and it was generally agreed that it's better to stick with the existing conventions used by the scripting language. tejon in particular was offended by supposed "C-chauvinism".

I remember that, but I'm thinking primarily in terms of how I write mathematical formulae. If I write something ambiguous like "cos t + C", I'd assume the C is not included, personally.

I think we need JRoush to weigh in on this one. If it's possible for OBME and/or AddActorValues to create new spell schools and assign them to new skills, then it definitely ought to be an AV return and GetSpellSchool2 is necessary. Otherwise, I'm good with the old return format. Will PM him.


Redundant commands again, feh. You have my vote, but it's your neck if mods get broken so do what you must.


Well! That's utterly non-obvious from the teaser info we'd been given about that feature. Of course, it's also in the docs but I didn't read that section because from the teaser info, I didn't think I'd have any use for it in the script I was writing. Impressive, though, and I hate the redundant alternates as much as you. Thanks for the pointer!