LarryG on 17/5/2016 at 01:26

---

I have a case where I have 6 unique looking Easter eggs which I don't want to have to take 6 different inventory slots, so I am combining them in inventory via Combine Type: EEgg. The eggs all use the same .bin file for the shape which uses texture replacement to make 6 differently died eggs.

Is there any way when dropping an egg from inventory to use a replacement texture based on the number of eggs remaining in inventory? That is, if none left in inventory, the dropped egg's texture replacement would be the #1 egg texture. If one is left in inventory after dropping, the dropped egg's texture replacement would be #2. And so on up to texture replacement #6.

I'm thinking something triggered by "Create" as that's the only message I see when dropping from inventory. Maybe something that increments a QVAR on "Combine" and decrements the QVAR on "Create" and somehow uses the QVAR value to change the replacement texture on the newly created egg when dropping one. Maybe by deleting a metaprop and adding in a different one just for the replacement texture?

I can almost see the shape of this, but not fully. Any thoughts?

Edit: I think that NVMetaTrap may be the ticket:

Quote:

you can use the NVMetaTrapQVar parameter to specify a quest variable to append to the end of the metaproperty name. For example, an NVMetaTrap with NVMetaTrapQVar="Difficulty"; NVMetaTrapMeta="M-Diff" will check the value of the "Difficulty" quest variable, and then append that number to the end of the metaproperty name, e.g. "M-Diff0", "M-Diff1", "M-Diff3", etc

I think if I have metaprop per egg that specifies the replacement texture, that may work ... remove it first on Create, and then add it back according to the qvar ... "Create" decrements the qvar and "Combine" increments it. It may be that simple.

Nope. Not that simple.

LarryG on 20/5/2016 at 00:06

---

I think you are referring to ModelByCount in the Public Scripts package

I believe I've got everything working reliably, except for a couple of last one weaknesses, using a custom stim and a few receptrons.

Features:

* The inventory model for the Easter eggs changes as you add items to the object's stack in inventory, going from a display of one egg, to two different eggs, to three different eggs, and so on.
* Eggs are dropped in last-in-first-out order withe the corresponding texture to its stack position. So if the last egg you picked up was egg #5 in your stack, when you drop it you will get and Egg #5 texture on it, no matter what it was going in. The next egg you drop will get a #4 texture and so on.

Weaknesses:

* I could not figure out a way to preserve the going-onto-the-stack textures and had to settle for a fixed order regardless of what order the concrete eggs are picked up.
* I have not yet figured out how to get the inventory displayed shape to automatically change when dropping eggs.

The Setup:

* Create a custom stim called EggStim
* Add a receptron to the Avatar>Garrett archetype for EggStim with effect "Permeate into container" and a coefficient of 1 for the Effect data. The range can be 0 to no max. This will pass on EggStims to any objects in Garrett's inventory
* Create 6 fnord>Property Sets, call them EEgg1, EEgg2, ... up to the number of different Easter Eggs you have. I have 6 different ones, so I created 6 of the property sets.
* On each of the property sets put the properties that you want to modify by stack count. In my case, I have 6 different egg textures that are on on a single replaceable texture egg model, and 6 different inventory models which show 1 egg, 2 eggs, 3 eggs up through 6 eggs being contained. So on EEgg1 I put Renderer>Alternate model: Eeggs1 and TxtRepl R0: Obj\TXT16\EEggs01. On EEgg2 I put Renderer>Alternate model: Eeggs2 and TxtRepl R0: Obj\TXT16\EEggs02. And so on. The S/R setup will use these to change these properties on the contained eggs.
* Create a qvar QvarEggs initialized to 0.
* Create a concrete marker with the NVTrapSetQVar script on it and Trap>QuestVar: +1:QvarEggs. Name it EggsNVTrapSetQVar
* Create your Eegg archetype. It gets NVTrigContained and NVRelayTrap as scripts. NVTrigContained takes care of the 1st egg getting picked up and the final egg getting dropped from inventory, but it doesn't deal with any subsequent eggs getting picked up or drops prior to the final one. That's what the NVRelayTrap is for. The Editor>Design note to handle this is {NVTrigContainedTDest="EggsNVTrapSetQVar"; NVRelayTrapOn="Combine"; NVRelayTrapOff="Create"; NVRelayTrapTDest="EggsNVTrapSetQVar";}. Just this bit gets QvarEggs to always have the correct count of the eggs in the stack.
* Add receptrons for EggStim to the Eegg archetype. Since I am changing two properties on six versions of the egg, I needed 2 receptron per egg for a total of 12 receptrons. Each pair is identical except for the stim ranges. I used 0 to 10, 10 to 20, 20 to 30, 30 to 40, 40 to 50, and 50 to 60 for each pair, one to change the Renderer>Alternate model for egg 1 another to change the TxtRepl R0 for that same egg. They all use Agent: Set property with Target object: Me, but the Agent object changes for each pair. The Agent object for the stim range 0 to 10 is the fnord, EEggs1. The Agent object for the stim range 10 to 30 is EEggs2. And so on. The first receptron of each pair has Effect Data: InvRendType. The second of each pair has Effect Data: OTxtRepr0.
* Now all we need are 6 EggStim sources with 6 discrete intensities of 5, 15, 25, 35, 45, and 55 tied to QvarEggs stored value. For this I created 6 markers each with the NVTrigQVar script. The first one checks for QvarEggs =1 using a Trap>Quest var value specified as =1:QvarEggs, to check for QvarEggs =1. . The second uses =2:QvarEggs, for QvarEggs =2. and so on. Each also has an Editor>Design note similar to {NVTrigQVarAllowRepeats=1; NVTrigQVarTDest="Player"; NVTrigQVarTOff="Null"; NVTrigQVarTOn="[5.00]EggStim"}. The only difference in this note between them is the intensity of the stim getting sent. This way as the qvar value goes up or down, EggStim at the appropriate intensity is sent to the player who passes it on to the contained egg object. The egg object then changes the two specified properties to match the stack count.



Whew!

I vaguely recall there was a way to go up and down in the inventory via a script. I'm going to look into whether there is an unobtrusive way to do that when dropping an egg.


Edit: There is. Adding a marker with the tnhscript CommandControl and the design note: on="cycle_item 1"; off="cycle_item -1"; gets the inventory to cycle up and down in response to a TurnOn followed by a TurnOff. I then added a new NVTrigQVar marker with design note: NVTrigQVarAllowRepeats=1; NVTrigQVarTOff="Null" and a Trap>Quest var value specified as >0:QvarEggs. This sends a TurnOn everytime the value changes. This marker is CD linked to the CommandControl marker and to an inverter which is then also CD linked to the CommandControl marker. This gets both TurnOn and TurnOff sent every time, refreshing the inventory display of the egg.

The only way I can see to improve this would be with a custom script. And I don't see that happening.

LarryG on 21/5/2016 at 14:00

---

Yep, as long as the player can't drop the eggs, a much simpler approach is possible. But as soon as you allow dropping of the eggs, it all goes bad. I think the S&R and Qvar approach outlined is does the job cleanly.