Docking Standard Proposal: microUSD

[benjwgarner]

A StarMade Community Docking Standard Proposal: microUSD

YouTube Video


Video Transcript
​

Hello, fellow StarMade players!

As a docking and standardization enthusiast, I have been been following the development of the community's USD docking standard very closely and I am a big fan of the current result, which I will be referring to in this video as "Draft USD". However, as several players have mentioned, there is one major use case that is not covered by the USD standard so far: very small spacecraft, such as short-range or carrier-based fighters.

To that end, I would like to introduce my proposal for what I am calling: microUSD.

Here I have a small fighter that I call a Sentinel. As you can see, it is much too small to support Draft USD. However, I would still like to dock it to stations or ships in such a way that the connection appears to seal. The solution: microUSD.

The docking connector portion of microUSD is identical to Draft USD, so they are mechanically compatible for docking spacecraft together purely for structural connectivity without the capacity for crew or cargo transfer through the hatch.

The difference lies in the fact that the hatch is located directly between the docking blocks and is only 1x1 rather than 3x3. For aesthetic reasons, I have elected to position the rail docker aft of the hatch facing forward, and the basic rail forward facing aft, although these positions could be reversed in a final standard. Unlike Draft USD, these positions are reversed on the support craft that the fighter is docked to for the same reasons of symmetry that an image in a mirror appears reversed horizontally but not vertically.

In terms of egress, the optimal position for microUSD is on the top of the fighter and the bottom of the support craft. This allows a pilot to enter from the support craft's gravity simply by dropping down into the fighter. The pilot can re-enter the support craft by moving upward independent of gravity after exiting the fighters core.

This configuration was inspired by the egress method on TIE fighters in Star Wars in which pilots enter fighters mounted on rails from catwalks into a top hatch. As such, this configuration also works inside of hangar bays.

microUSD is not, however, limited to solely this orientation and will work when aligned in any direction when used in combination with directional gravity, even horizontally.

Thank you for viewing my proposal. I would appreciate your support for including microUSD in the community's USD docking standard. Together, we can make sure no fighter is left behind.

 

[Malacodor]

You have my support. My Mining Vessel is already microUSD (and normal USD) compatible.

 

[Krougal]

I came into this thread thinking...Oy Vey! Here we go again.

But honestly well done. It's a good idea, you presented it well (I mean who the hell can argue with Star Wars coolness). It's simple (unlike some peoples ideas) Because it isn't strictly USD 1 compatible (since most of us have the center block blocked) it's a use case that does merit a different name.

 

[NeonSturm]

The only questions now are:

• What happens on bigger docks? 5x5, 7x7, 9x9?
• 
  
• Should there not also be a standard for even symmetry? 2x2, 4x4 ...
• 
  
• Where should the dock be placed and what features should be provided by dock/ship?

./ . . \
/ . . . \
[]-----[] - It's obvious they can't dock.
\ . . . /
.\ . . /​

 

[benjwgarner]

The only questions now are:

• What happens on bigger docks? 5x5, 7x7, 9x9?
• 
  
• Should there not also be a standard for even symmetry? 2x2, 4x4 ...
• 
  
• Where should the dock be placed and what features should be provided by dock/ship?

./ . . \
/ . . . \
[]-----[] - It's obvious they can't dock.
\ . . . /
.\ . . /​

Bigger Docks

So far, larger docking standards have not really been needed because the only thing we are transferring seems to be an approximately 1x1x2 player. In the future, this may become necessary as new play styles or game mechanics are introduced (standardized cargo containers, anyone?). In the near term, players who prefer larger docks can employ multiple docking rings (some large, some standard) on their vessels or use adapters like in Mind Lord's video.

Even Symmetry

In my experience, even symmetry is difficult to work with and has no significant advantages over odd symmetry in voxel games. My general impression is that this sentiment is shared by many players, and I would like to avoid excessive standards proliferation to the point where nothing is compatible because no one is using the same standard. That said, we may need to create such a standard so that the players who prefer even symmetry could all use compatible docks. Again, multiple docking rings or adapters could be the solution here, too. Here's what I think an even standard should be if we were to create one:

USD Type 2​

​

Ship Guidelines and Features

I think that any further specifications for exactly how USD Type 1 should operate would be excessive and counterproductive. Let's leave it to each individual shipwright to decide on the specifics such as logic controls, number of plex doors, plex door locations, gravity modules, number of blocks between the outer surface of the hatch and the first door, and other such considerations.

Some guidelines for locating the dock on the vessel itself may be useful, however. Your example would obviously not dock without a rail system that extended a docking tunnel past at least the outermost surface of the ship. Another idea for ships with bilateral symmetry would be to ensure that the dock extended out past the outermost surface of the ship toward one direction along its length rather than both, which would allow ships that were wider than the hatch either in front of or behind the hatch to dock (but not both). Ships with opposite wider parts would dock facing the same direction, while ships with the same orientation of wider parts would dock facing opposite directions.

(Note: the blue light indicates the front of the ship.)​

Final Thoughts

I hold none of this as dogma. All standards, at their core, are (or should be) designed to meet the needs of the community. As these needs or preferences change, the standards can change accordingly.

 

[Krougal]

Yeah, don't mind Neon, he has a penchant for over-thinking and over-engineering.
Standards need to be simple and flexible enough and just can't cover every possible use case.
As Valiant70 , Fireshock and myself have posted in screenshots on the USD-1 thread, there is a lot of flexibility behind and above the docking blocks.

One thing that did occur to me, the kind of small ships that would most likely see the use of your micro idea are also the ones most people are going to want to have on sliding rails (like the tie fighters in your video) so rail orientation needs to take that into account. For example, even though my cruiser has the USD-1 docking port & airlock, the shuttle I just released for it doesn't work with it or your micro-USD idea, because the shuttle bay rails along with reactor placement won't allow for it.

 

[benjwgarner]

Yeah, don't mind Neon, he has a penchant for over-thinking and over-engineering.
Standards need to be simple and flexible enough and just can't cover every possible use case.
As Valiant70 , Fireshock and myself have posted in screenshots on the USD-1 thread, there is a lot of flexibility behind and above the docking blocks.

One thing that did occur to me, the kind of small ships that would most likely see the use of your micro idea are also the ones most people are going to want to have on sliding rails (like the tie fighters in your video) so rail orientation needs to take that into account. For example, even though my cruiser has the USD-1 docking port & airlock, the shuttle I just released for it doesn't work with it or your micro-USD idea, because the shuttle bay rails along with reactor placement won't allow for it.

Yes, Neon does have that tendency, but over-engineering is an important job and somebody's got to do it. We need some people to push the bounds of what is obvious or reasonable in order to make sure that we're not missing anything.

You make a very good point about mounting small ships on rails. In the video, the TIE fighters seem to either be mounted on rails on the bottom of the cockpit or on either side on the pylons that the wings are mounted to (although that video's adherence to canon is called into question somewhat by the fact that some kind of rotating turbine is clearly visible in the full version whereas, according to canon, the TIE/Ln's engine has no moving parts).

I'll upload another video to this thread sometime in the next 72 hours addressing this issue since I have some ideas.

EDIT: could you please post some images of your shuttle and rail system so that I can get a better idea of how your setup works?

 

[Viridis00]

On one hand, I think it's nice to have more standardization. But on the other hand, I can't really get behind a USD for fighters because in my opinion the rail basic is a wasted block for a fighter. Fighters will dock to support ships and stations, but rarely if not ever will anything need to dock to it like with medium to large ships.

The ingress hatch thing is a cool idea too, but not all types of ships will support that kind of function in their design. When you get small you don't really have the luxury of going "yeah just slap a hatch on it somewhere and make a corridor connection" for certain types of design.

The most universal method of docking a fighter should be an open landing pad or landing bay. Anything else should just be proprietary around the fighter's design, not the other way around.

 

[Krougal]

Yes, Neon does have that tendency, but over-engineering is an important job and somebody's got to do it. We need some people to push the bounds of what is obvious or reasonable in order to make sure that we're not missing anything.

You make a very good point about mounting small ships on rails. In the video, the TIE fighters seem to either be mounted on rails on the bottom of the cockpit or on either side on the pylons that the wings are mounted to (although that video's adherence to canon is called into question somewhat by the fact that some kind of rotating turbine is clearly visible in the full version whereas, according to canon, the TIE/Ln's engine has no moving parts).

I'll upload another video to this thread sometime in the next 72 hours addressing this issue since I have some ideas.

EDIT: could you please post some images of your shuttle and rail system so that I can get a better idea of how your setup works?

Mine is very basic, I have some in my shipyard thread (last post, spoilers), although they don't show it in motion. I need to do a video. The shuttle is up for download, but the cruiser is still very much a WIP.
So the docker is at the very front bottom of the shuttle, it's actually USD-1 "compatible" but not "compliant" (you can dock it, and it only partially obstructs the airlock...so it is useable)
[DOUBLEPOST=1432342668,1432342560][/DOUBLEPOST]

On one hand, I think it's nice to have more standardization. But on the other hand, I can't really get behind a USD for fighters because in my opinion the rail basic is a wasted block for a fighter. Fighters will dock to support ships and stations, but rarely if not ever will anything need to dock to it like with medium to large ships.

The ingress hatch thing is a cool idea too, but not all types of ships will support that kind of function in their design. When you get small you don't really have the luxury of going "yeah just slap a hatch on it somewhere and make a corridor connection" for certain types of design.

The most universal method of docking a fighter should be an open landing pad or landing bay. Anything else should just be proprietary around the fighter's design, not the other way around.

Yeah, agree about the rail basic actually too...I can't really think of a situation where you want to dock to a fighter or shuttle. The Warbler has only a docker (well and a turret axis, but that's on the roof).

 

[benjwgarner]

On one hand, I think it's nice to have more standardization. But on the other hand, I can't really get behind a USD for fighters because in my opinion the rail basic is a wasted block for a fighter. Fighters will dock to support ships and stations, but rarely if not ever will anything need to dock to it like with medium to large ships.

The ingress hatch thing is a cool idea too, but not all types of ships will support that kind of function in their design. When you get small you don't really have the luxury of going "yeah just slap a hatch on it somewhere and make a corridor connection" for certain types of design.

The most universal method of docking a fighter should be an open landing pad or landing bay. Anything else should just be proprietary around the fighter's design, not the other way around.

Well, this isn't a final standard so the rail basic can easily be removed. The reason I included it was primarily for the rare cases in which fighters may need to dock to each other (a functioning fighter rescuing a pilot from a disabled fighter, for example) but, again, this is a community standard rather than a "benjwgarner thinks this is cool" standard, so your mileage may vary. :p

Yeah, "slap a hatch on it" doesn't really work at this scale (which was why I thought at least some kind of standard may be helpful). The most universal method is absoultely an open landing pad, but that doesn't have a "sealed" hatch connection which was the idea here (whether or not that is even needed in the first place is an important question, though. The TIE fighters certainly don't have that.) Jath Tech has a great video on landing platforms and other methods for fighter docking without an integrated hatch for those who are interested. To me at least, "sealed" hatch-based designs have a certain elegance that escapes "just stick it in a hangar with an atmosphere" approaches, but then again, the shiniest spaceship isn't necessarily the most effective.

I agree that fighters shouldn't be shoehorned into a certain configuration in order to comply with a docking standard, but that wasn't really the point of my proposal. This is designed so that those who do want a "sealed" hatch design can use a compatible standard.