More on actions.

RawrRawr REGISTERED, Tester Posts: 503 Seed
function example:PrimaryAction()

function example:DefaultPrimaryAction()

function example:GearPrimaryAction()

function example:RangedPrimaryAction()

function example:HitPlayer()

function example:HitCharacter()

function example:HitScriptedObject()

function example:Throw()

function example:SecondaryAction()

function example:OnObjectSecondaryAction()

function example:AffectMaterial()

function example:AffectObject()

function example:Interact()

function example:Use()

function example:Bounce()

function example:Consume()

function example:ProduceDrops()

function example:PlaceObject()

Part of this was me looking up what functions I could use for porting Portal Stones in the advent of the loot system. I ended up feeling a bit bemused and so decided to looked at the problem from a designers perspective instead.

So the initial question is, why so many functions? I mean, could you more or less boil them all down to:
function example:Action()

function example:Reaction()
I have two thoughts towards this why question.

The first is that this is a by-product of building on old code, of which I'm not going to deny that there's definitely an argument for re-using code. At this point however I'd argue it looks more like something that should be refactored.

The second is minecraft. How so? Well there's this interesting thing that happens in MC where after punching a block, it drops into the players hand. Well... it looks like the block is in the players hand but actually as far as MC is concerned, nothing has changed and you can keep punching away at other blocks as normal. Interesting right? Holding blocks doesn't change the players actions. What a kicker, because as soon as the player holds a tool, boom, actions change. I think this is a problem and TUG is in the same boat; Holding voxels doesn't change actions but tools do.

Just to be clear about that, I'm imagining the left mouse button as being responsible for executing all actions an object may execute on another object(s). This builds the case for just this type of action to be assignment to this button.

But what's the real question here?
How do we define actions.

I'm of the opinion that one type of action is like a conversation. First, an object defines its action(s) and/or reaction(s). Then, that object may execute it's action on another object. The other object then reacts to that action. Part of the other objects reaction may be to execute it's action(s). Lastly, if the other object took any actions, the initial objects subsequent actions may change.

To make that more concrete: Let say we've got a player looking at some dirt with empty hands. Let's say we've also got a mod such that a dirt voxel's reaction to a player with empty hands is to be picked up into the players hand. The player executes their empty hand action on the voxel. The voxel's reaction to the players action starts up it's action to put itself into the players hand. The players reaction to the voxels "put me into your hands" action is successful. Now the player's action changes because of the voxel in it's hands.
Programmer, designer, artist.


  • johnycilohoklajohnycilohokla REGISTERED, Developers Posts: 283 Developer
    I'm not sure why you have picked those specific functions, half of them are internal functions.
    But since you have picked those ones I will go through them, hopefully that will clear thing up a bit:

    - Interact (target, mouse right click)

    - PrimaryAction (object, mouse left click)
    - SecondaryAction (object, mouse right click)
    - RangedPrimaryAction (internal, part of Equipable:PrimaryAction)
    - DefaultPrimaryAction (internal, part of Equipable:PrimaryAction)
    - AffectMaterial (internal, part of Equipable:DefaultPrimaryAction)
    - AffectObject (internal, part of Equipable:DefaultPrimaryAction)

    - HitPlayer (internal, part of OnContactStay, contact event)
    - HitCharacter (internal, part of OnContactStay, contact event)
    - HitScriptedObject (internal, part of OnContactStay, contact event)

    - GearPrimaryAction (internal, currently hard coded to Gauntlet)

    - OnObjectSecondaryAction (internal, passes the event to the AI system)

    - ProduceDrops (part of Lootable, used to produce drop for an object when it breaks)
    - PlaceObject (internal function of the Lootable class, used by Lithari:PlantMushroom to place random mushrooms)

    - Bounce (internal function of the Bouncy class, used for Mushroom bed/tree)
    - Consume (internal function of the ConsumesFuel class, used for add fuel to a crafting station)
    - Throw (unused, part of the old Throwable system)
    - Use (unused, part of the old Usable system, replaced with SecondaryAction)

    Hmm... I usually think about left click (PrimaryAction) as breaking/attacking and right click (SecondaryAction) as using the item you are holding or interacting with an in-game object.
    Also while holding a voxel the SecondaryAction action changes, it is used to place that voxel.
    I'm not sure I follow your idea, what should the PrimaryAction do while you are holding a voxel? or vines/stick?
    My Blog
      yt.png  t.png  
  • RawrRawr REGISTERED, Tester Posts: 503 Seed
    edited November 2015
    Ah! some good points.
    The commonality that I was trying to draw out of all of those functions was that they're all related to actions.

    The second part of me highlighting those functions was bringing to light exactly what kind of logic should be define where. This is what I eluded to with my last question - how do we define actions? Once we sort out some definitions, I'll know which functions I should be defining.
    As an example, within the Equipable.lua script we call PrimaryAction on left click, which then calls DefaultPrimaryAction which then calls either AffectObject or AffectMaterial. Why not just PrimaryAction and then go straight to AffectObject or AffectMaterial?

    I'm aware of the usual way in which we think about making actions (attacking / interacting) but half the reason why I start these posts is to challenge those assumptions. The intent is to create room for testing.

    Keeping with the voxel in hand for a moment. The idea is about having the PrimaryAction/Action reflect that fact, as oppose to thinking about moving it to the right mouse button.

    Give me a moment, I'll try put this into code.
    ...Could be some time though. Still in the middle of sorting out Mixin's.
    Programmer, designer, artist.
Sign In or Register to comment.