Better interactive exits

Bugs & Features
#1

We’d been using exits that point to the same exact room for a while now, how about we formalize them as a thingy?

Here’s what I suggest.

Just like you can create an exit, you can create an interaction. Interactions have all the same exact properties as exits, sans the arrival message. To facilitate with less characters, both leave and travel messages for interactions should allow double the amount of characters (I know at least one place that hit the limit).

Interactions can be used by clicking on them (in a separate interactions panel similar to exits) or by using go. Functionally they would be exactly as the exits with the target room being the same as the origin one. It’s just that there would be no double mesages as there’s no arrival message.

To make it a bit nicer, I also suggest the following two things.

The use command as an alias to go. We want to support the legacy exits but nudge people to use the new system.

The $name in the leave mesage will be expanded to character’s name. If there are several places it’s used in the leave message, all if them will be expanded. If there are none, the usual formatting with having the name prefixed to the message will be used. This slows to be more expressive for the inreactor but keeps things easy for the others as the travel message still uses the standard formatting.

4 Likes
#2

I expect this is the sort of thing that would roll out with the scripting at some point, and I want this, then! Unless it ties in to anything function wise, is this any different mechanically than a drop-down option you can click on to read more?

1 Like
#3

Scripting is still so far out and this is what people across the rift do already. I merely propose to make it nicer to use.

is this any different mechanically than a drop-down option

those aren’t in the main buffer. There’s no sense of continuity and being part of the IC interaction. Everything from the post office to the sex machines in the stables uses self-exits to provide interactivity. Clicking on the drop downs is inherently OOC.

1 Like
#4

Ah! That’s a fair point. I didn’t consider them being in the buffer or showing up in a log.

1 Like
#5

I’m down, and had some similar thoughts too a bit a go. Maybe, there’s some ideas in there to mix and match. [Feature] Actions

1 Like
#6

I like the idea, and this is something we want.
And yes, it is very much lie @Jett’s suggestion with [Feature] Actions .

While I was writing this reply, explaining how I wanted to do it with scripts, I started to realize that maybe you are right; maybe we should ALSO have actions/interactions, for simpler things. And LATER add scripts?

I was worried interactions/actions would become a feature soon to be deprecated once we get scripts, but it may actually be something needed for simpler interactions which may exist despite the existence of scripts.

Anyway.
What they would have in common with my script thoughts is that “interactions” should in that case be able to register custom commands, rather than having to be prefixed with use.

Custom Command

A custom command would be exactly that; a command - similar to all of our other commands, like go, say , etc. So, instead of a specific use command, you can register any pattern. E.g.:

turn on jukebox
push button
shuffle cards

I want to use these for scripts as well; and in that case you would be able to register them on different levels:

  • objects (when we have objects)
  • rooms
  • areas
  • realm

In case of conflict, a higher level (such as realm-level commands) have priority over lower level commands (such as room-level commands).
Built-in commands (like go) will have highest priority, and will never be overridden.

For interactions, this would be simple room-level commands, but the idea is to also support future scripting ideas that @Farcaller brought up in his post about Simple scripting implementation idea. His use-case would be realm-level commands for things like bankers.

I still need to work on how to define these commands, but in the end I want them to feel native, with tab-completion, color coding, and built in help.

Let me poke a little more with these thoughts.
Maybe I can make a simple Proof-of-concept with the custom commands, and showcase it.

2 Likes
#7

I was thinking that this bit is easier to make use work and then we’d get to cleaning up the existing interactions and make the whole experience smoother. And when you get the scripting we’ll just move over to that.

2 Likes