LarryG on 12/12/2014 at 04:22
I'm looking for a way to force the dropping of an object in inventory when another (different) object is picked up. For example, there are concrete objects A, B, and C in the misison. The player picks up A. Then the player picks up either B or C. I want that to force dropping of A. If the player picks up A afterwards, then whichever is in inventory (B or C) gets dropped. The player can only have one of the three at any time. And I haven't found any script that will force the player to drop an object. Is there one? I would accept a teleport solution, but I don't think you can teleport out of inventory, can you?
Yandros on 12/12/2014 at 04:38
Can;t you just remove the Contains link from the player?
LarryG on 12/12/2014 at 05:16
Well I don't know if one exists or not ... You're thinking using NVLinkBuilder to remove the links? NVLinkBuilder only allows 4 copies, so that would limit me to 5 objects. Pick up one and have the WrobWorldEnd trigger the 4 NVLinkBuilders on the object to attempt to remove the Contains links from the other 4 concretes, only one of which could be contained and maybe not even one. Maybe. I can put the NVLinkBuilders on a metaprop with the design notes on the concretes ... Maybe an A/R approach and an NVRelayTrap on each concrete that sends a stim on FrobWorldEnd to itself. Then the receptron uses that stim to remove any Contains links on any number of concretes. Was that what you were thinking, Russ? But what if the concrete in contained by a lockbox? I'll have to look at this and see. Maybe, as you say, remove the link from the player to the concrete instead of from the concrete to the player, the way I was thinking ... But FrobWorldEnd may not be the right trigger because the object may be given to the player ... maybe use the "Contained" message as more direct ... There are possibilities here, but I'll need to work on it to figure it out. Thanks. Would have been nice if there had been a script I overlooked to just drop the object on TurnOn. Oh well.
Xorak on 12/12/2014 at 05:43
I think you can directly teleport trap out of the inventory, needing nothing else to make it work. I think I did it in my first mission. (Confirm: yes it's very easy to do). I did remove an item from the player's inventory for certain, and I've been trying to check how I did it, but it's quite a mess. :eww: It's like going back to figure out what code does without any comments.
What you're describing is essentially the setup I had in that mission, where something would be removed from inventory and replaced with something else (though I did it secretly so the player never noticed) but my setup is quite archaic.
Yandros on 12/12/2014 at 12:35
I hadn't thought through an implementation, but S/R seems a simple way to go. However I thought you only had 3 such objects, not an arbitrary number, so I'm not sure what the best approach is.
LarryG on 12/12/2014 at 15:14
Sorry, I used three objects in the example, but I plan to have a currently undetermined number. The exact number to be determined by difficulty. Which is a reason that I think the dropping mechanism has to be on the object being dropped with a broadcast (message or stim) triggering the dropping. The solution needs to be robust enough to work with dynamic adjustments to the objects affected at initial Sim. The more I think about it the more I think that the A/R approach is the most flexible in this regard with, maybe, NVTrigContained as the source of the Stim. We'll see.
R Soul on 12/12/2014 at 15:50
The trigger is easy enough with S&R. For each object, give it a 'contact' stim. Propagator: Frob in world. On the Garrett archetype add a receptron whose effect is permeate into container.
If you just remove the Contains link, the object won't appear by the player but at the last place the player had it selected. The response should be for the object to create a new instance of itself, then delete itself. The standard emitter trap script would work but the location could not be guaranteed. I think NVCreateAndLink is the best script to use.
Give each object the receptron effect 'send to scripts, which allows stims to become script messages. The object can be created relative to the Player object. I don't know if orientation is taken into account. You may be able to get away with not specifying link details because some parameters have default values. If you have to set the link, just use something that won't interfere, like a CD link to itself or an innocent marker that's just minding its own business.
And NVDeleteTrap with the NVDeleteTrapDeleteSelf=1 parameter. The description says that allows it to delete itself after deleting CD linked objects. Since you have none of those, it'll just delete itself when turned on.
LarryG on 12/12/2014 at 18:45
I don't think using a Contact stim and FrobInWorld will work for objects stored in containers. The object isn't getting frobbed, the container is and it uses the Container script to give the object to the player. Maybe I can have the container use FrobInWorld and a Contact stim on it to take care of the cases where the objects are in containers, and have the same setup on the objects for when they are dropped so if they are picked up again off the floor, the same thing will happen. The tricky bit would be to time it all properly so that the container does the stim before doing the giving of the object. Otherwise the object will get the stim too and get dropped ...
Needs thought and experimentation with all the silly things players might do to break this.
(Why not NVSlayMeTrap instead of NVDeleteTrap? Better yet, why not do the delete/create using the same stim. As long as I have the stim, receptrons can take care of both)
qolelis on 13/12/2014 at 07:45
Are all objects of the same type? Could you get away with deleting an object and then recreate it? If so, maybe you can use
NVStackOrDropTrap to simulate a drop (delete the object in inventory, send TurnOn to
NVStackOrDropTrap to drop a new instance of it (if you add the script to the player object (or an object attached to the player), you can specify an offset from the player for the new object)), and then add the frobbed object to the player's inventory.
If the objects are not always the same type, then maybe they can have a common ancestor which you specify in
NVStackOrDropTrapObject!? I haven't done any tests, though, so maybe I'm just being delirious.
Quote:
NVStackOrDropTrap (
NVTrap)
Upon receiving TurnOn, this script checks if the player is currently carrying an item of the type specified by NVStackOrDropTrapObject. If he is, then the stack count of that object is increased by 1.
If the player is not carrying an item of that type, then one will be created in the world. The object will be placed at (0,0,0) unless the NVStackOrDropTrapLoc parameter is specified. If that parameter is given, then it is an offset from the location of the script object, or else the object specified by the NVStackOrDropTrapLocObj parameter. You can also use NVStackOrDropTrapRot to specify the rotation of the newly created object.
LarryG on 13/12/2014 at 08:20
I looked at NVStackOrDropTrap early on, and the description made literally no sense to me. It seems this trap only takes TurnOn messages. It still makes no sense to me.
In any event, the objects will be all different.
No, I think the A/R approach is probably the best one. If I get this to work, I'll post a follow-up as to how.
