Got a question about the PluginAPI and RegisterStringVarInterface(). Now that argument extraction is done through the script interface would it be correct to assume I no longer need RegisterStringVarInterface()? Looking at the code there are no calls leading to it.

yes when i downgrade to b5 or b6 it works again

Hi I have a little question about the GetName function.
I understand that it returns a string with the display name of an item,
however i noticed that depending on the font size the display name might be longer or shorter (i.e if the full name of the item is too long to display it will be shotrtened)
I tested this using vanilla and DarN UI.

My question is:
Is the GetName Function returning the Full Name or just the displayed name? My limited testing sugests the latter.
Can anyone confirm that?

Secondly is there any way to implement a function to get the full name? (as shown in the CS)

Thx

bliviongate:

Why not use a user function to do the job ? You can always box the caller script's variables and pass it as an argument.

RegisterStringVarInterface() should no longer be necessary.

Thank you. I'll look into what OBSE functionality CCAO is using that may have changed between beta 6 and the current version.

GetName returns the name as defined in the CS. Depending on how you're displaying the result the name may be getting shortened after it's returned from GetName.
Feel free to post code and output.

Pretty much this. If the calling script is a quest script you don't need to worry about boxing up local variables.
Alternatively you can write a really ugly spaghetti-style script with Label/Goto to jump into and out of your subroutine code.

Yeah, like combat style, the name is defined on the base object, so the solution would be similar. I'll add it to the todo list.

Nvm I just retested and it worked ok, I'm thinking that wryebash was the culprit since I had not rebuilt the batch after changing the esp, the first time

Any chance in 21 of getting functions to update the teleport list for a random door? E.g. the ones to Oblivion Worlds, Sigil Towers or Oblivion tunnels. They have the same issues as leveled lists, in that any mod that updates the vanilla list gets its changes overwritten by a second mod doing the same.

bliviongate:

What do you want to be able to do to the lists besides adding to them - do you need to be able to remove things too?
Do you need the changes to persist with the savegame?

Thanks for the obse update.

I previously asked for a version of PlayIdle that does first person animations. Well, I want to add an additional request. You know how playing idle animations disables your ability to equip/unequip items from your inventory, and displays a message similar to "You cannot change weapons while attacking". It would be great if you could create a version that doesn't prevent you from (un)equipping items. It's not a high priority for me but I think it could be useful.

Adding is the main need, of course, but I wouldn't say no to removing, and a query function to see if a target is already there.

I'd have no problem with using GetGameLoaded/Restarted to make sure the entry's there (assuming query or Add ignoring a duplicate), so savegame persistence is probably not needed from the mod script's viewpoint. However, I believe a random door needs to save its paired door in the savegame once it's selected, so that it's repeatable after reloading. The player should be able to return through the same path reversed. That may make savegame persistence for the list a requirement to prevent a crash before the script can repair it.

Not a request for once, but thanks.
I'm really impressed with PlayIdle. Pretty much what I wanted. It's going to make things so much easier!
I can't imagine using PickIdle ever again!

wrong thread! :blush:

bliviongate:

bliviongate:

scn zzFunctionOSarray_var aResultbegin function { }   let aResult := ar_Construct Array    if GetDead == 0  if GetInFaction ILikePizza == 1 && GetInFaction ILikeBurgers == 0 && GetInFaction ILikeSoda == 2 ; Means I eat too much.   let aResult[0] := 1let aResult[1] := 1.5  endif endifsetFunctionValue aResultend...let aTemp := I.call zzFunctionOSif eval ((ar_Size aTemp))   let IEatTooMuch := aTemp[0]   let IDrinkBadly := aTemp[1]endif

This should reduce the amount of code duplicated. The bottom line is that refactoring your script's code to use user functions a bit cleverly seems like a more viable option than implementing a fairly sophisticated tool like the one you suggested. If a 'SetScriptVariable' type of function were to be implemented, you'd be able to water it down even further.

I wouldn't be concerned about memory usage when it comes to scripts, FWIW.

Because of this* and many other reasons, I find myself moving more and more variables to quest scripts. Someday I will end up with no object script variables at all. Lol.

By 'this', I mean object scripts and functions accessing the same set of multiple variables (nowadays, I have 95%+ of my code in user functions).

bliviongate:

Won't it ? By replacing that block with a UDF call and the subsequent local variable update will result in less bytes written to the script's compiled data . The script text sees a reduction in length as well (that should be quite obvious). The snippet I posted is parent-agnostic as the local variables are updated inside the calling script, after the function call. I don't see why it can't be used as you intend it to :shrug:

Reduction in size is always good - I didn't say it wasn't. My point was that in the current context (a couple of KBs of bytecode, give or take) isn't gonna reflect much at runtime (Oblivion's masterfile contains ~2400 scripts that amount to ~ 3500Kb, inclusive of script text). Even if you've got 100 scripts compiled to the brim (16KB each), you've only setback the runtime heap by 1.6MB. Compare that to what a 1024x color map would consume (4MB giving 4 bytes to each pixel).

First off, belated congrats on the release.
It's great to see this is still making that much progress.

I was away from the scene for a while, and honestly aren't really fully back, yet, but at least I'm finally able to use the CS again and test things out ingame. I even started fixing and improving my scripting approaches lately.
A little overwhelmed by the many new features of the OBSE releases I missed during my inactivity I'd like to ask for some clarification on how some things work.

Namely I'm wondering about the function set like "ModMaleBipedPath" or "CompareMaleBipedPath". According to the docs those were always meant to also work on references, yet with all inventory access functions you could only get the items as base objects, so this never was a question before.
But now that we have this shiny new way of accessing inventory references directly I'm wondering if calling those functions on such a reference will only affect the 1 instance of the item in the inventory or if they will still affect the base object and thus all instances of the item in the game at once. And if they only affect the 1 instance, how would I go to make this change visible? Update3D on NPCs and on the player sticking to the UnequipItem->EquipItem solution?
You might have an idea why I'm asking this, considering how much more useful it'd be to get rid of my CloneForm-based approach with all its inherited drawbacks I have to take care of in my scripts. So I hope they really only affect the 1 instance of the item this way and won't touch the base object anymore.
But actually I only need to get some clarification on this, no matter what's the answer.

And thanks for the SetPlayerSkeletonPath. It seems to be working like a charm so far. I'm now able to rid my mod of the need to "replace" skeletons which was causing so much incompatibility already.
And again this opened a whole new world of things I can do now, switching skeleton and complete set of animations on the fly. :bowdown:

Commands that affect the base object do so whether you call them on a reference or pass in the base object as an argument - this doesn't change if the calling reference is an inventory reference. Data like model path, name, etc is defined on a per-object, not per-reference basis, so we can only change it on a per-object basis unless we override the game code that accesses it (whether or not that's a practical option depends on how the game accesses it).

Any changes you've made to an item currently worn by an NPC will become visible on that NPC if you call npc.Update3D.

Thanks for the clarification. I had the distant hope this could be changed for one instance only, but now I at least won't have to rewrite my whole approach.
So I'll stick to my CloneForm-based approach. Thanks to your new functions for inventory references I can now at least retrieve and set health and charge of the items I'm swapping out, so swapping an unfitting item to a fitting one will not lead to it getting fully repaired and recharged anymore, no matter if they're currently still equipped or not anymore. And thanks to your EquipItem2-functions I won't have to take care of OnEquip events not firing anymore either.

While we're at it, I lost track of what happened to the idea of an alias-list for cloned forms (equivalent to the one for races), so functions like GetEquipped will also return true when it's actually a cloned form of the base form that was asked for and functions like GetEquippedObject and my favourite GetEquipmentSlotMask will return the original base item instead of the cloned form (by default). This will work wonders when Vanilla quests or other mods will think it's the item they're checking for although it's actually a cloned form of it. We were talking about it for a while before I had to leave the scene quite some time ago.

Not looked in detail at the scripts that's discussed, but I fully agree with others that UDF's are all you need. You can manipulate any number of quest variables, and nothing stops you from adding a large number of out variables to an array and then using "SetFunctionValue myArray" - letting you return as many out variables as you'll ever need.

Hi folks.

I seem to be having some trouble with GetEnchantmentCost. It continually returns Zero.... which makes the later division by it kill the script... The code in question:

let temp2 := ( getobjectcharge object )
let temp3 := ( getenchantmentcost object )
Printc "AM- charge %0f Cost %0f" temp2 temp3
set quantity to ( temp2 / temp3 )
printc "AM- Quantity %0f" quantity

Get object charge works fine. GEC.... doesn't.... the object is a cloned bow, if that matters.

bliviongate: