Forum rules - please read before posting.
Tech questions during the weekend? Drop in on the community Discord channel!

Reducing level design overhead:(maybe) Feature Request: Adding "Self" to parameters

Hi there!

I ended up with something like this to re-use an "open door" actionlist asset.

It feels like there's a lot of clutter and overhead to just pass a Transform of the marker, two transform of the door hinges, 2 rotations and disabling "self".

It's not rare to reference the same object an ActionList (asset, with parameters) gets triggered from.

That is, referencing a Hotspot from the very same hotspot the asset actionlist gets triggered. Maybe (typical scenario), to disable it once it's been used. Or to get the coordinates from it.

It's probably a bit too scripting - related, but I'd love to know if this could be added to the list of features. I know it's a bit of work, but I'm unsure about how to avoid having to add so much overhead to do something as basic as linking a hotspot to an actionlist which opens a door.

Do you suggest extending the Hotspot class, or adding a behaviour "Usable Door" to the same Hotspot, which handles everything at Awake like: adding the "Use" action to the hotspot, attaching the actionlist, passing the custom parameters to the Actionlist?

I'm trying to do as less configuration on the Hotspot as possible, delegating everything to another component, if this is the best way to do it.

I'm a bit unsure about how to do it, tho.

For instance, given a DoorHotspot Monobehaviour, not inheriting (or maybe yes, as a replacement) from Hotspot, how could I, without breaking anything on Awake, add an "Use" interaction, then attaching an asset Actionlist to it, and passing other parameters (maybe one like GetComponent() as "Self")?

My fear is about compromising something in AC's logic or throwing some runtime error at some point. Are there good practices or things I should avoid doing, or should I do, during Awake or Start, to make everything run smoothly?

Is there a way to add a HotspotDoor (inherited from Hotspot) to the quick-add list of object in the AC Scene tab? Or, it's faster to add a second component after adding the default Hotspot?

What's your suggestion?
Should I be adding "Constant ID"s at edit time?

Comments

  • Is there a way to add a HotspotDoor (inherited from Hotspot) to the quick-add list of object in the AC Scene tab?

    No, but I shall consider if it's possible to extend this through script.

    You can modify the original Hotspot prefab if you wish - inside /AdventureCreator/Prefabs/Logic - to add any component you want part of all your game's Hotspots.

    Should I be adding "Constant ID"s at edit time?

    They should only be added at edit time. Did you mean runtime? These need to be kept the same at all times, so should not be added dynamically once the game begins.

    Do you suggest extending the Hotspot class, or adding a behaviour "Usable Door" to the same Hotspot, which handles everything at Awake like: adding the "Use" action to the hotspot, attaching the actionlist, passing the custom parameters to the Actionlist?

    An ActionList's parameters can be set at runtime, and if you hook into the OnHotspotInteract custom event then you could avoid using the Set Interaction Parameters component.

    Bear in mind, however, that you should be able to prefab the Hotspot in your above screenshot - you then shouldn't need to keep assigning each GameObject parameter field for each instance. So long as the Constant IDs have Retain in prefab? unchecked, multiple instances won't conflict since they'll be given new IDs upon placing them in the scene.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.
Do NOT follow this link or you will be banned from the site!