Additem does not mimic vanilla behavior

Involved development of the OpenMW construction set.
Post Reply
Equinox
Posts: 19
Joined: 31 Jul 2018, 20:13

Additem does not mimic vanilla behavior

Post by Equinox »

Code: Select all

begin test
if ( barreltesting->getitemcount, ingred_bread_01 == 0 )
            barreltesting->additem ingred_bread_01 1
endif

return
end
This is a global script. In OpenMW, The script only works on 1 barrel, and other similar barrels (same ID) are not.

To test this , download and use this esp , go to caldera, ghorak manor, and search the barrels. OpenMW and Vanilla.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Additem does not mimic vanilla behavior

Post by akortunov »

A quite strange global script.
It will look for first instance with "barreltesting" ID in game world every frame (a quite slow, avoid to do that!) and will check if it has the bread (ingred_bread_01) inside it.
If the bread is not found, the script will add it to found barrel instance (yes, AddItem adds item to object instance).

If your approach is a "add a bread to the every barrel, which does not have it", more likely you did not implement it right.
kuyondo
Posts: 243
Joined: 29 Mar 2016, 17:45

Re: Additem does not mimic vanilla behavior

Post by kuyondo »

akortunov wrote: 01 Aug 2018, 09:49 A quite strange global script.
It will look for first instance with "barreltesting" ID in game world every frame (a quite slow, avoid to do that!) and will check if it has the bread (ingred_bread_01) inside it.
If the bread is not found, the script will add it to found barrel instance (yes, AddItem adds item to object instance).

If your approach is a "add a bread to the every barrel, which does not have it", more likely you did not implement it right.
I tested this in vanilla and it works fine and without any noticeable performance loss. I suppose this script is okay if used for few items.

I also this tested in OpenMw, the script only works for 1 barrel.

Andrei, do you have alternative script implementation? Without editing the object directly in the CS..
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Additem does not mimic vanilla behavior

Post by akortunov »

kuyondo wrote: 01 Aug 2018, 11:24 Andrei, do you have alternative script implementation? Without editing the object directly in the CS.
Actually, I'd just add the script to the "barreltesting" object.
Equinox
Posts: 19
Joined: 31 Jul 2018, 20:13

Re: Additem does not mimic vanilla behavior

Post by Equinox »

akortunov wrote: 01 Aug 2018, 12:48
kuyondo wrote: 01 Aug 2018, 11:24 Andrei, do you have alternative script implementation? Without editing the object directly in the CS.
Actually, I'd just add the script to the "barreltesting" object.
Im trying restock a vanilla container using that script, example a diamond mine.. But if i do so like you say, it would reduce compatibilty with other mods that also attach a script. IIRC, we can only attach one script per object in the CS.

In any case, the vanilla implementation looks superior to me, because it can affect many containers at once..

Im not sure why OpenMw can only
kuyondo
Posts: 243
Joined: 29 Mar 2016, 17:45

Re: Additem does not mimic vanilla behavior

Post by kuyondo »

akortunov wrote: 01 Aug 2018, 12:48
kuyondo wrote: 01 Aug 2018, 11:24 Andrei, do you have alternative script implementation? Without editing the object directly in the CS.
Actually, I'd just add the script to the "barreltesting" object.
That would cause problems, if other mods also wants to add script to the object. It will reduce mod compatibility.

If we do it, like Equinox said, at least we dont have to modify the barrel. We dont want to modify a vanilla container if possible.

IMO, vanilla implementation is superior because it affects all ID, not just 1 instances of the ID.
NullCascade
Posts: 121
Joined: 16 Jan 2012, 07:58

Re: Additem does not mimic vanilla behavior

Post by NullCascade »

I think this is related to the bug with the ordinator armor. OpenMW doesn't edit base records.

The vanilla engine has instances and base objects for containers, NPCs, and creatures. These base objects have their own inventory. When one of these is cloned, it is copied from the base inventory. Similar to AI package information, I don't think OpenMW lets you edit these base objects. `"ordinator"->setflee 100` and `"ordinator"->additem gold_001 1" won't edit the base object. In vanilla adding the item to the base object will make it so when the container is cloned (when it is opened, not when it is spawned) it will have it.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Additem does not mimic vanilla behavior

Post by akortunov »

kuyondo wrote: 01 Aug 2018, 14:18 IMO, vanilla implementation is superior because it affects all ID, not just 1 instances of the ID.
It DOES NOT affect all objects.
It just spams barreltesting->getitemcount calls in hope that search by ID will find different objects during different calls. In this case "getitemcount" and "additem" actually can work work with different objects. Probably it is not intended behaviour.
I do not know how it works in vanilla, but OpenMW looks for first object with given ID, preferring active cells.
So you can call this script 1000 times, and it will find the first object with given ID in current cell 1000 times. Obviously, it will be the same item.
Unfortunately, vanilla script engine does not provide a reliable way to work with non-unique objects.
Probably you need to use MWSE in this case.

EDIT:
I specially tested vanilla game: tried to add a glass sword to non-unique quard and unique NPC:

Code: Select all

"hlaalu guard_outside"->additem "glass longsword" 1
heddvild->additem "glass longsword" 1
Result is a quite interesting: for guards it did not affect existing guards, but affects newly spawned ones.
If I select a guard in console, and run

Code: Select all

additem "glass longsword"
only selected instance is affected.
For unique NPC result is opposite: it does not affect newly spawned instances, but affects existing reference.
Even if another instance of this NPC is added in game world (e.g. via script), NPC still is considered as unique and script works only with original instance.
Highly likely there are another quirks here.

For now, looks like console commands for objects (with ->) work in this way:
1. Check a count of existing instances of target object in game (take only instances from ESM/ESP files in acoount).
2. If there is only one instance, modify it and do not touch base record.
3. If there are many instances, modify base record, but do not touch existing instances.
Probably effect depends on console command.
Post Reply