Skip to content
This repository has been archived by the owner on Sep 2, 2019. It is now read-only.

Parent / Attach system #13

Open
ElusiveMori opened this issue Dec 28, 2018 · 2 comments
Open

Parent / Attach system #13

ElusiveMori opened this issue Dec 28, 2018 · 2 comments

Comments

@ElusiveMori
Copy link
Owner

ElusiveMori commented Dec 28, 2018

@LinearBoundAutomaton proposed adding a parenting/attachment system to YARP2.

Standing questions:

  • Should we use units or special effects for attachments?
  • How will the user experience look? Commands, spells, etc.?
  • What are the performance implications for updating/moving these attachments? It is likely they will need to be moved every frame for a smooth experience.
  • What changes need to made in the Save/Load system to support this? (This is mostly my job)

@LinearBoundAutomaton, please provide a short summary of how you envision this.

@ElusiveMori
Copy link
Owner Author

Here are my personal thoughts.

I think we should use the existing EffectProxy package and extend it to suit our needs.

Regarding UX, there's 2 approaches I can think of:

  1. Purely command-based syntax:
  • attach <id> to attach a model with the specified id to the root of the unit.
  • atch list list all attachments on the unit, with their IDs, from 0 to ...
  • atch 0 x/y/z move an attachment
  • atch 0 p/y/r rotate an attachment (pitch/yaw/roll)
  • atch 0 scale scale an attachment
  1. Unit-based system
    You spawn a regular unit/building like you would normally, and give it a special ability, e.g. aa parent. You position the unit however you'd like next to the parent unit, and then cast that ability on the parent, turning the unit into a special effect and calculating all the relative offsets, at which point the unit is removed.

@ElusiveMori
Copy link
Owner Author

Setting this as low priority while LBA has gone silent. Will work on this later.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant