Return to “Suggestions”

Post

Joint Node Editing (UI)

#1
Regarding Nodal Interface...

I played a little VR and tried to... use... an interface like that.
None of this actually exists so this is going to be a little abstract (and maybe a little verbose, too =) so buckle up.
  1. The interesting thing about it that it could be an interface without scale or scaling.
    Ordering a fighter to attack or ordering all fighters of 3 joint fleets to attack is the same thing.

    Classic interfaces struggle with this because there is a vast gap of hierarchies between all these different elements. But if you remove scale from the equation...
    RTS use workarounds like "select all fighters" or "select all units of this type" but that lacks control. (which isn't a major issue when clicks per minute matter more)
  2. For that, there needs to be a way to mark one or multiple nodes above what you are editing.

    For instance, I want to switch out weapons, replacing the weapon in hardpoint 1 with something else.
    • I mark the carrier as a joint node.
    • Then I scroll down to Fighter 3 and exchange the weapon.
    • Since Fighter 4 is also a child of the joint node, the same thing is done with it.
    If I had marked the carrier + Fighter 1, three fighters would have had their weapons switched.

    If I had marked the fleet, all fighters in it would have had their weapons switched.
  3. The match condition is where it gets a little tricky.
    Does it affect all fighters (what is a class?) or specifically those built with the Enhanced Gazznium Hull?

    Different hulls would have different kinds of properties so the safe thing to do would be to keep them separate at all times.
    That automatically creates different squadrons on a carrier or in a fleet because by marking the carrier as a joint node, you could give an order to "all heavy fighters"... who happen to have the same hull type.
    Without ever creating an explicit wing or squadron for it.
  4. If part of the carrier's fighters (which were affected by the command) were airborne or otherwise unable to execute the instruction,
    the joint node object develops a burning desire to make it happen.
    Subordinate fighters are being recalled and if possible equipped with available stores.
    New items may be ordered from a supply ship or the carrier might go looking for a (your?) factory where they are being produced.

    Since the joint node object takes care of this, organisational structures aren't ripped apart, like a lone fighter haring off to find a Polarity Reversion Launcher.
  5. How a node would be marked as "joint"?
    Dunno. A qualifier key, a menu button. *shrug*
  6. Un-marking a sub-node.
    If the fleet is already marked as a joint node, I perform the "joint" click on the carrier.
    The carrier and all it's subjects are removed from the selection.
    Simple toggle.
  7. Visualisation.
    When a node is marked as "joint", it and everything below it would be a different colour or shape.
    That would let you see what's in the selection while scrolling up and down.
  8. RTS Grouping Deluxe

    If you have selected all the joint nodes you want, you use CTRL-4 to save that selection.

    This isn't a complete unit list like in Starcraft but something more abstract.
    If the carrier gets 2 new fighters as reinforcements, a later recall of that selection would again select the carrier (and all that it contains) so the new fighters are in the selection without you having to manually "update the group" every time a stupid fighter gets delivered.

    Since the toggle is remembered, units that were removed from the selection stay removed when it's recalled.
  9. If you lost the carrier, all surviving fighters would become members of fleet.
    If you want to re-assign them to a new carrier, you mark the fleet, then unmark all surviving carriers in it.
    Only the fighters directly assigned to fleet remain in the selection and can be dragged to a different object aka the new carrier.
  10. Command focus.
    Is also remembered.
    At the time you saved the selection with CTRL-4, the object type you had highlighted is recorded.

    In our example it was probably the fighter's weapon hardpoint.

    The next time you recall the selection, all members of previously selected joint nodes are again selected and one object of exactly matching type is highlighted... so you can give a different order on the same issue.

    I could use the same selection and save it to different groups... one time with the interceptors highlighted, the other with the bombers highlighted.
    Or I use one of them and a mouse flick gets me to the "other" kind of fighters on the carrier.
    With the slection selected and the object highlighted, I can start giving orders.
node.jpg
Stick figures. Because they are cool.
node.jpg (74.95 KiB) Viewed 3731 times
This here is all about working within established structures in your fleet / property list.
In a different topic (Ship Roles) I'm exploring a related issue on the macro level, outside these structures.
There is no "I" in Tea. That would be gross.
Post

Re: Joint Node Editing

#2
+2378 for that article

I'd add the suggestion to save joint nodes as "blueprints".
For example you could store carrier + fighters + support ships as a joint node and recall them later as build orders
This blueprint should also store standing orders

Example: the carrier has 3 destroyers as escorts which each has 5 fighters as escorts. The fighters have the carrier as homebase. Also there are groups of 5 fighters "squadrons" on standby in the carrier. These squadrons could be tied to "virtual" nodes which are not an object in itself but only contain 5 fighters each

If you order the build of the joint node of carrier+destroyers+fighters the finished fighters start to protect the destroyers which in turn start to protect the carrier.
The same with single squadrons of the carriers fleet.

No hassle setting up large fleets as you just replicate the joint nodes
Last edited by Cornflakes_91 on Wed Nov 27, 2013 6:17 am, edited 1 time in total.
Post

Re: Joint Node Editing

#3
I'd like it if the formation editor could do a lot of these grouping allow for more situational awareness when picking options.
If you're making 2 subformations of fighters in a carrier group, then it speaks to reason you'd be able to interact with those 2 groups, or with the entire formation. I'm still in love with the idea of an advanced formation editor that allows you to play tactically.
Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Post

Re: Joint Node Editing

#4
Cornflakes_91 wrote:I'd add the suggestion to save joint nodes as "blueprints".
That would have to be "a" node in this structure.
A complex construct that spans multiple branches of the tree with gaps inbetween... is really messy to maintain.
  • What would work is if you take the FLEET node in that graphic and save it as a snapshot.
    That would save all hierarchies, ship types, equipment, and cargo.
  • Whenever this fleet needs to check for maintenance and supply, it would compare it's own structure to the snapshot.
    Instant shopping list.
    Same with replacing losses. The fleet knows what ships got blown up.
  • I walk up to a ship yard manager and hand him this list.
    Build this fleet. KTHXBYE.
  • The combat readiness of a fleet can be displayed easily because it would be possible to show losses by overlaying the TOE with the present units.
    No need to save arbitrary statistics for that purpose.
There is no "I" in Tea. That would be gross.
Post

Re: Joint Node Editing

#5
Gazz wrote:
Cornflakes_91 wrote:I'd add the suggestion to save joint nodes as "blueprints".
That would have to be "a" node in this structure.
A complex construct that spans multiple branches of the tree with gaps inbetween... is really messy to maintain.
You either mean with nodes and joint nodes different things or i dont undestand why it should be messy

Just store the node with subnodes as blueprint and if you want to add that blueprint anywhere just drag it out of your list onto the node where it should be attached as child
Post

Re: Joint Node Editing

#6
Katorone wrote:I'd like it if the formation editor could do a lot of these grouping allow for more situational awareness when picking options.
If you're making 2 subformations of fighters in a carrier group, then it speaks to reason you'd be able to interact with those 2 groups, or with the entire formation.
Hmm. Fleet organisation.

What if organisational sub-structures could be shadowed to a certain top level?

In this example I put up 2 fighter wings.
One is a fixed complement of a carrier.

When operating this fleet I could navigate down to Wing Bravo and give it an order... or use the shadow of Wing Bravo that is pegged to the fleet node.

Then I can organise a fleet all nice and proper with different carriers, a light and heavy section... whatever... but the fleet node would give me direct access to the shadows of the structures that I intend to command.

When ordering the carrier around it would always take Wing Bravo with it but if needed, I can grab the wing directly from the top level.


One one hand it's a bad idea because it duplicates entries but on the other, it lets me generate "quick access" structures which are automatically maintained in a fleet's TOE so they always work for this type of fleet all throughout the empire.
No need to set up hotkeys before every damn fight because when a "fleet type 1" is built, all my "bookmarks" are already part of the structure.


What would be required is basically a paperclip button to "pin" the wing or unit.
If it's not a top level node, it's shadowed to the top level.
Sub-units are not shown. They remain part of the "true" TOE... which you can navigate the long way around if needed.
The shadows are for quick access and nothing else. Don't make this messier than it needs to be. =)
node2.jpg
Now with extra colour!
node2.jpg (73.31 KiB) Viewed 3695 times
Oh and: TOE = milspeak for Table of Organisation and Equipment
There is no "I" in Tea. That would be gross.
Post

Re: Joint Node Editing

#7
Gazz wrote: One one hand it's a bad idea because it duplicates entries but on the other, it lets me generate "quick access" structures which are automatically maintained in a fleet's TOE so they always work for this type of fleet all throughout the empire.
No need to set up hotkeys before every damn fight because when a "fleet type 1" is built, all my "bookmarks" are already part of the structure.
I think it's exactly this which will make the node interface very powerful. You're getting multiple ways of going from an overview to a detail.

Fleet -> By Type -> Fighers -> Wing Bravo
would be the same as
Fleet -> By Formation -> Carrier -> Wing Bravo

Got a transporter assigned to your fleet that's in charge of resupplying ammo? The tree will let you understand how the transporter relates to each of these ships, but will also allow you to get quick access to the transporter's command interface as well.
Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Post

Re: Joint Node Editing (UI)

#10
Thanks Gazz for starting another fantastic thread :)

This is something that has been on my mind a lot as well. The idea of performing actions on groups of nodes. I'm also thinking about viewing the data within groups of nodes at the same time.

What I was thinking is similar but a bit different - instead of marking nodes in a certain way (e.g. as "joint nodes"), what if we simply allow the selection and expansion of groups of nodes in the exact same way that we expand a single node?

Consider, for example, if you select a group of fighter nodes. You drill down into them. What you see is a "merge" of all of the fighter structures. Nodes that exist in all fighters will be "unified." For example, you might see a "health" node that shows a range, maybe an average, maybe a distribution, whatever. In this manner, you can visualize the "health" of an entire fleet in the same manner as the health of a squadron, etc. You can issue orders to the whole fleet in the same way that you issue orders to a single unit, etc. How all that would work is to be determined. But the idea is conceptually simple: attempt to merge the nodal structures :)

The harder part is figuring out how to deal with structural differences. Just needs more thought :)

Anyway. There's so much opportunity for doing amazing things with this kind of interface...very excited to hear thoughts on it :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Joint Node Editing (UI)

#12
JoshParnell wrote:Consider, for example, if you select a group of fighter nodes. You drill down into them. What you see is a "merge" of all of the fighter structures.
....
How all that would work is to be determined. But the idea is conceptually simple: attempt to merge the nodal structures :)
It could be a deliberate "organisational node" that you insert to merge specific things that you want merged.
Like those wings in my scribbles.

An entire wing of fighters would be handled / commanded as one object and have health / supply values.
If the creation of such a wing is deliberate, fleet organisation can be as simple or as complex as the player desires.

Also, if a fleet has a TOE (building plan...), you could grab a bunch of fighters and bigger ships and assign them to "the fleet".
According to the TOE they would fill empty slots (losses), bringing the fleet back up to strength, and any excess ships would end up in an automatically generated "reinforcements" container at the fleet's top level.
That way the don't "mess up" your organisation but it may have to be an optional mechanic.


With the "shadow" mechanic I outlined, the top level organisation of a fleet would show all "important" elements (with their health and such).
For more details you can drill down to supporting elements that are not needed as often.


I don't think we're talking about different things here. =)
There is no "I" in Tea. That would be gross.

Online Now

Users browsing this forum: No registered users and 1 guest

cron