Proximity pick closest

[delgelato]

Hi,

I've had the DS for a while but only now starting to integrate. I'm hoping the package will be able to replace a lot of my own home-made system..

The main question for now is about the Proximity registering the last entered as the active Usable.

In my system there's Interactable, that's what it's called. Planning to switch every Interactable to Usable eventually. Would it better to modify the Usable or keep my own Interactable to control the Usable (to not tamper with the package at all)?

Anyways, the player keeps track of every Interactable nearby, got its own display of what's currently the active one, which is whatever is the closest, even if he's among many Interactables. Pressing F, say if he's among 3 Items(object with Interactable) will pick them up 1 by 1 starting from the closest.

I read in the changelog that Proximity Selector is now virtual and I can override it, but just wondering if there's already a way to select from the closest without doing so. If not, I'll make a derived class, but where should I look?

Also, if I switch all my pick-able items to contain the Usable, and just have a UnityEvent to call "PickUp" on the item, it's fine right? As in, the Usable is meant to be used for non conversation usable stuff too?

The next question (slightly related), is, I have my own Item class and Item DB containing the general item info. Currently the item's detailed effects are defined in a prefab for each item. I'm thinking of improving this in the future, so everything about the item is contained in the DB, modularly build the item's details with scriptable object parts.
Can the "Item" DB in the DS be linked to my item DB? I read around here about getting variables from c# in lua that this can be done.
So, should I use DS's ItemDB at all?

Great asset, btw. Excited to fully integrate them in my project. There'll be more questions to come

Cheers!

[delgelato]

Ok so the Use the closest Usable is done, overrode the ProximitySelector to update which one's closest, and only call the OnDeselected stuff when the closest is changed.
Haven't done the item pick up with Usable. Currently thinking of just, when Use(), call PickItem on the Item MonoBehavior and from there disable the Usable when picked up(and the collider).
I'm just wondering if there's any implication in using Usable on pickables that disables the Usable. I guess I'll just have to try.
But the last question of the first post is still there: should I be using DS's ItemDB at all to replace my item-inventory system? I'm imagining I'll keep it separate (or not use DS's ItemDB) and entirely use lua to check c# variables like HasItem / HasAmount in the player's Inventory class.

[Tony Li]

Hi,

Ok so the Use the closest Usable is done, overrode the ProximitySelector to update which one's closest, and only call the OnDeselected stuff when the closest is changed.
Haven't done the item pick up with Usable. Currently thinking of just, when Use(), call PickItem on the Item MonoBehavior and from there disable the Usable when picked up(and the collider).
I'm just wondering if there's any implication in using Usable on pickables that disables the Usable. I guess I'll just have to try.

Since you're subclassing ProximitySelector, add a method called something like DeselectUsable:

Code: Select all

public void DeselectUsable(Usable usable)
{
    if (usable != null) CheckTriggerExit(usable.gameObject);
}

This cleanly removes the Usable from the ProximitySelector's list and selects the next Usable in the list. Call it before disabling the Usable.

But the last question of the first post is still there: should I be using DS's ItemDB at all to replace my item-inventory system? I'm imagining I'll keep it separate (or not use DS's ItemDB) and entirely use lua to check c# variables like HasItem / HasAmount in the player's Inventory class.

Use your own item-inventory system. The Dialogue System's Item[] table is just a table of data; it doesn't have the code functionality that I'm sure your own system has. Registering Lua functions is the way to go. That's what the Dialogue System's third party support packages for Inventory Pro, Inventory Engine, etc., do.

If you want to integrate your item-inventory system with the Dialogue System's save system, make a copy of Plugins / Pixel Crushers / Common / Templates / SaverTemplate. This starter script has comments that explain how to fill out the RecordData() and ApplyData() methods. For examples, see the scripts in Common / Scripts / Save System / Savers.

Then add your script to the scene, for example to the player GameObject. (Or the player prefab if the player gets instantiated at runtime.)

[delgelato]

Since you're subclassing ProximitySelector, add a method called something like DeselectUsable:

Did it a bit differently. "Just" the GetClosestUsable is done in Update, and only if it's different than the current Usable then it calls CheckTriggerExit on previous closest Usable.

So I'm still wondering about picking up items. Since I'll use "Usable" in every gameobject Items that the player can pick (and possibly examine before pick), should that object represent an "Item" or "Actor"? Or neither(because it should work if just to call Usable)?
Or if it's Actor, then maybe it'll be under a generic "ItemObject" ?

Also, I hope you don't mind I ask some extra minor questions in this thread. The bigger questions will have its own thread.

In DialogueSystemTrigger, I see this:
/// <summary>
/// Deprecated in favor of Dialogue System Action Trigger.
/// The Dialogue System Trigger is a general-purpose trigger that can execute most
/// Dialogue System functions such as starting conversations, barks, alerts,
/// sequences, and Lua code.
/// </summary>

But I can't find what's Dialogue System Action Trigger. Just to make it clear. DialogueSystemTrigger is the trigger to use for general-purpose, right? Or is it (will be) deprecated?

Also, I was looking around the recipe, but it seems some are outdated? Haven't checked all but particularly this one.

I ended up using DialogueSystemEvents because it's the only one that has OnConversationStart/End. But it has no Condition to put the Lua.
Also tried to put this disable component at start in the DialogueSystemTrigger of the Npc instead, which has Condition for Lua, but this is just a trigger. There's no OnConversationEnd equivalent if I use this.
And I'd have to change all DST in the scene to include this logic (and add the player's PlayerInput reference in code when the Player object's created at runtime) <- anyhow, the Conversation Event should be in the Player anyways(like in the recipe). Is there a way to do this now?

Cheers!

[Tony Li]

Hi,

In DialogueSystemTrigger, I see this:
/// <summary>
/// Deprecated in favor of Dialogue System Action Trigger.
/// The Dialogue System Trigger is a general-purpose trigger that can execute most
/// Dialogue System functions such as starting conversations, barks, alerts,
/// sequences, and Lua code.
/// </summary>

But I can't find what's Dialogue System Action Trigger. Just to make it clear. DialogueSystemTrigger is the trigger to use for general-purpose, right? Or is it (will be) deprecated?

Hmm, I'll check out that comment and fix it. DialogueSystemTrigger is the trigger to use, and it will not be deprecated. The older trigger scripts (ConversationTrigger, LuaTrigger, etc.) will stick around for compatibility; they just won't be front-and-center in the Component menu.

Also, I was looking around the recipe, but it seems some are outdated? Haven't checked all but particularly this one.

That's the version 1.x documentation. There's no Recipes page in the version 2.x documentation. The Recipes page in 1.x had become the equivalent of the household junk drawer, containing an unorganized jumble of miscellania.

The SetComponentEnabledOnDialogueEvent component is still supported, but it's not presented in the Component menu. Instead, to do something when a conversation starts, add a DialogueSystemTrigger set to OnConversationStart. Then add a Set Components Enabled/Disabled action to it. You can also set the trigger's Conditions section.

To run actions when the conversation ends, add another DialogueSystemTrigger set to OnConversationEnd.

[delgelato]

To run actions when the conversation ends, add another DialogueSystemTrigger set to OnConversationEnd.

Implying there can be multiple DST in an object. Was wondering about this and this is great news!
Ok, enough questions for now. Time to put them all together!

Cheers

[focusonfungames]

Ok so the Use the closest Usable is done, overrode the ProximitySelector to update which one's closest, and only call the OnDeselected stuff when the closest is changed.

Would you consider open-sourcing this?

Tony, just to confirm: by default, Proximity Selector always selects the most recent entry into the trigger as the current Usable, right?

[Tony Li]

Tony, just to confirm: by default, Proximity Selector always selects the most recent entry into the trigger as the current Usable, right?

Yes, that's correct. If that Usable leaves the trigger area, the next most recently-added Usable becomes the current Usable.