GECK ammo lists overwrite each other

[Mktavish]

Hmmm not sure if you are on to something there ... but in that case . The reference before the dot is the container , and the item after the function is that which is in the inventory. And I think both the container and item would probably accept a base-ID. I think the 2 different lines there , are just showing you can use the syntax of "Enchanment" in place of "ObjectEffect" since enchantment is a hold over from Oblivion. ^shrug^

With a form-id before a dot ... or no dot starting with a command ... I just thought the first was explicit , and the second implicit ?

 

This seems to have been added so you can have an inventory item cause effects ... since the equipment slots are trimmed down compared to Oblivion.

 

And Bing!!! That just added some idea's for me how to get stuff done in my mod ... Thanx for the mention :smile:

[EPDGaffney]

Actually, the way it works is that if you use ref.GetObjectEffect, in that case ref must be a reference or the script will not work. So, say there's an armour item lying on the ground in a cell and that item is stored as ref, then GetObjectEffect will tell you the armour's enchantment (which will be the enchantment on the base item, despite being called by a reference), if and only if it's called as ref.GetObjectEffect.

 

Now, if you called it as GetObjectEffect ref, it would return nothing, because ref is not currently storing a base ID.

 

But say you decided to store the player's currently equipped armour (player.GetEqObj 2) as ref and now you want to know its enchantment/object effect, well in that case, if you called it as ref.GetObjectEffect, it would return nothing, because ref is now storing a base ID.

 

So, in this example, to get the object effect of the armour the player is wearing, you let/set ref to player.GetEqObj 2

let ref := player.GetEqObj 2

and then run something like

let rEffect := GetObjectEffect ref

to store that effect in a variable.

[Mktavish]

Hmmm sorry I edited stuff up there ... which you didn't see.

 

But instead of useing "ref" could you put in an actual ID so I could better understand ? ... mainly is it a base , ref or variable.

[EPDGaffney]

In my example, ref was a ref variable, and ref variables can store reference objects and base objects, so it depends entirely on what you've done with the variable before using it.

 

So, what I was trying to illustrate is that if you use ref to store a reference object, you would need to use

ref.GetObjectEffect

But if you use ref to store a base object, you need to use

GetObjectEffect ref

The major thing to keep in mind is that these functions will compile with no errors even if you mess them up, because the script isn't checking for what's stored in your ref variable, just that a ref variable is usable where you've used it.

 

However, if you use an actual ID instead of a variable, the script will be able to give you an error instead of compiling. So, if you lay an armour in the world and give it a Reference ID of ArmorPowerT45dRef, then

ArmorPowerT45dRef.GetObjectEffect

will compile and

GetObjectEffect ArmorPowerT45dRef

will not. Likewise, you can call the script on ArmorPowerT45dRef's base object with

GetObjectEffect ArmorPowerT45d

but

ArmorPowerT45d.GetObjectEffect

will not compile.

[Mktavish]

Yes there is no dot to be used unless is explicit . Otherwise it has to be implicit ... due to the script being attached therefore is the subject of the script.

But I do think that in some cases a base-id can be passed there ... Atleast besides just "Player"

Many do need the ref ... and like I mentioned earlier ... Passing the form-id created at drop in ... can sometimes yield better results.

 

I am unclear what you mean here ...

 

"But if you use ref to store a base object, you need to use

GetObjectEffect ref"

[EPDGaffney]

When it's implicit, you don't need to put anything to define the calling reference, so yes, there's no dot in that case.

 

But when you use an explicit reference object to call the function, it goes before the dot before the function title.

 

And when you call the function on a base object, there is no dot and the base object comes after the function title.

I am unclear what you mean here ...

 

"But if you use ref to store a base object, you need to use

GetObjectEffect ref"

Well, the function in question can be called by a reference or on a base form, but depending on which one, the function will have different syntax, and that's simply the syntax for the base form.

 

See:

GetObjectEffect BaseForm

vs

RefID.GetObjectEffect

Does that make more sense?