Jump to content

Kerbin Mini Shuttle


helldiver

Recommended Posts

Do more attachment nodes make connections stronger?

Like say I placed four in between two segments?

No, the attachment hierarchy is linear - you can't attach a part to a vessel from more than one node. The attachment strength is specified manually per node.

Link to comment
Share on other sites

No, the attachment hierarchy is linear - you can't attach a part to a vessel from more than one node. The attachment strength is specified manually per node.

Alright, does it matter how many attachment nodes are on a part?

For example, cargo bay right now has 7 cargo pad attach points plus its front and rear attach points. We then have the two for the wings. So I'm wondering if I should have the gear attach to the cargo bay or the wings?

Link to comment
Share on other sites

Alright, does it matter how many attachment nodes are on a part?

For example, cargo bay right now has 7 cargo pad attach points plus its front and rear attach points. We then have the two for the wings. So I'm wondering if I should have the gear attach to the cargo bay or the wings?

The number of points does not matter too much - I do not think there is an upper limit. I think the gear should attach to the wings, not the cargo bay; otherwise, for example, if the player rips the wing off there is a chance that the gear bay would be left on the cargo bay, when really it should rip off with the wing.

Edit: One thing to be aware of though is the snapping distance in the VAB/SPH - if you have too many attachment points close together it can be difficult for the user to snap to the right one, but I can easily tweak the layout to deal with that.

Edited by ZRM
Link to comment
Share on other sites

The number of points does not matter too much - I do not think there is an upper limit. I think the gear should attach to the wings, not the cargo bay; otherwise, for example, if the player rips the wing off there is a chance that the gear bay would be left on the cargo bay, when really it should rip off with the wing.

Edit: One thing to be aware of though is the snapping distance in the VAB/SPH - if you have too many attachment points close together it can be difficult for the user to snap to the right one, but I can easily tweak the layout to deal with that.

I'll leave it up to you regarding dummy_attach_cargo_gear_left(right). They are both on a kingpin vertex that is shared with the wings and the main gear. Simply unlink it from cargo_bay and link it to their respective wing. The only thing I would do different is rename from dummy_attach_cargo_gear_left(right) to dummy_attach_right_wing_gear and dummy_attach_left_wing_gear respectively (unless you're using your own naming convention). Either way, let me know via PM if you reassign those attach points so I can do the same on the production files.

However, realistically the gear would be attached to the main root spar. In an event of a crash the wings are designed to rip off leaving the gear as intact as possible. So technically, the gear should actually stay on if the player were to rip the wings off since they are traditionally attached to the strongest point of the entire aircraft. Actually, believe it or not, on most real aircraft (dunno about the shuttle) that area has the most expensive and difficult to manufacture structural component, the primary former. In many aircraft it is made of a solid machined titanium slab. :D

The attach points in the cargo bay and engine mounting (on rear_end) are the minimum required. The reason why the mounting pads have two (01,02 and 04,05) are so that you can mount larger than off-center items on them. However, if you find 02 and 05 to be too close and unnecessary feel free to remove them. If you move any of the attach points on the firewall, the engines won't line up with the baked mounting location on the texture. If you think attach_rear_rear is too close to eng_01, feel free to remove it. However that attach point gives players a centerline location for mounting the shuttle symmetrically on top of a fuel tank.

Rear_end attach points rudder_01, 02, and 03 are to give players the option of a v-tail or standard rudder.

I think everything should have been spaced out appropriately. Let me know if you plan on removing or moving them particularly any that involve changing the form factor of the final assembled KSO.

Edited by helldiver
Link to comment
Share on other sites

I'm planning on several additions to the KSO.

-Lift vehicle

-Mini lunar lander consisting of a command pod, fuel section, rover container.

-Mini rover vehicle.

-I'm planning a robotic arm, but it won't work like the Canada arm of the real shuttles. Instead it will be more like a jack that facilitates release of the cargo you load on it. The arm itself would be on the floor of the cargo bay and lift/push cargo outwards.

Link to comment
Share on other sites

-I'm planning a robotic arm, but it won't work like the Canada arm of the real shuttles. Instead it will be more like a jack that facilitates release of the cargo you load on it. The arm itself would be on the floor of the cargo bay and lift/push cargo outwards.

I like this idea, it seems very kerbal-esque!

Link to comment
Share on other sites

In regards to KSP, what would be the gameplay function of a space lab?

I would rather spend the time making space station modules that fit the cargo bay of the KSO. You could use those modules as a space lab I'd imagine. In regards to no updates, the project is no longer in my hands and is currently being processed into KSP.

Unfortunately we've run into a few technical snags related to the Unity --> KSP process. Once all that is cleared up we'll begin the primary testing phase. During which I'll be fixing any art related issues and completing some of the artwork assets that didn't make it into the first phase such as emissives for the KSO to facilitate docking and other minor details.

Edited by helldiver
Link to comment
Share on other sites

A science lab might be useful in the next update, as seen here:

So, I've been thinking long and hard here about how we're going to do the 'earning science' bit. It's a good idea, but putting it in practice poses a few challenges.

How do we rate the science value of your missions? What even defines a mission in the first place? These things are actually pretty hazy in terms of how the game deals with them, so coming up with a nice, solid way of doing science is a deceptively tough task.

I do believe I've worked out a good solution now:

The game won't award you any science automatically. That would be artificial and generally meaningless, but worse still, it would require us to make arbitrary decisions about the science value of this or that action. That's a bad road to go down. Instead, we can let you 'do science' as part of your missions, and get your science points for yourself. Here's how:

We already have a few science sensor parts, which apart from a context menu readout, are largely decorative. We can put those to some use now, along with a couple other scientific parts we're going to add.

The idea is that science parts work as one-shot experiments. That is, they're activated by action group or as part of the staging sequence, and once deployed, they to their thing. This is essentially deploying the experiment to gather data. This data isn't science yet though, because you need to get it to your resident experts over at R&D to crunch the numbers and make some sense out of it.

To do that, you can recover the experiments (or whatever is left of them). That will convert the data you gathered into scientific knowledge, provided you don't already have it. This is done by us storing where each experiment was run and what it was, and using that 'source' as a key to a multiplier value, which starts at 100% and gets progressively lower the more data on the same subject you gather. The more you spam the same type of experiment in the same place, the less science you'll get for the data it generates.

Now, if we've learned anything this far, it's that recovery is by no means guaranteed. So here's where the antennas and comm dishes finally get a purpose. Once available, you can use comms equipment to transmit science data back down and gain science immediately. Of course, you can't expect to get as much knowledge for the same experiment data if you beam it back as if you had recovered it hands-on. How efficient the data-for-science rate is depends largely on the quality of the antenna being used, as does its power requirements.

The possibilities for what the science-gathering parts can be then are pretty huge. They could be anything from experiment canisters filled with some mystery goo, a camera array, a mass spectrometer, anything really. Functionally it all works the same way, and better yet, it works with the game rather than over it.

That's about it in a very tightly packed nutshell. I'm pretty happy with this idea now, it should fit any style of playing. You could focus on running as many different experiments as possible in Kerbin's lower atmosphere, or rush into discovering the different properties of Mystery Gooâ„¢ across the farthest reaches of the solar system, and hopefully any point in between as well.

Disclaimer: Mystery Gooâ„¢ is not really a planned feature (yet).

Cheers

But I don't really care what you make, because it's certain to be awesome anyways.

Link to comment
Share on other sites

I would -love- to do a space station "set" all compatible with the KSO.

Actually, I always had planned to eventually do that, since judging from the original pics of the orbiter I saw (the one I posted on the OP) most of the space station parts wouldn't fit inside it.

The set would consist of a series of modules that all fit inside the KSO. They be designed with:

-Gameplay and fun being #1. This would only come with the support of advanced modders such as ZRM and the others that have helped me in this thread, and from the devs.

-Easy of use. I'd rather be called a "cheat maker" than make random stuff that's a nightmare to deal with. For example, the moon lander that I plan to make for the KSO will have a lot of things already integrated into it. This makes loading and releasing it from the KSO simple and seamless. The vehicle itself would consist of a minimum amount of parts and would be designed with simplicity and modularity in mind. The mini rover vehicle would be designed to fit the lander while at the same time have ramps that clear its engines. The mini-rover would all be a solid vehicle with slots to attach instruments and batteries.

One reason why if I designed an arm, I'd want it to work centerline with the floor of the bay and push items outwards (or grab and pull them in). That would allow you to use the KSO to plot a coarse to a planet, release a probe/rover/lab component, and easily be able to retrieve it.

Another suggestion is: a manned pod in the cargo bay like the shuttle launch experience at NASA's KSC, (in Florida, not kerbin) it's like space lab, except its more like a bus

I like your idea. I'm against the idea of a cargo bay replacement "passenger cabin". I entertained the idea for a bit, but then realized that it just didn't make sense at all. Why would the Kerbals spend millions doing all the research, wind tunnel testing, building the orbiters, to then slice the thing up and install a passenger cabin airliner style?

From a scientific purpose perspective it just didn't make sense to me. I'd rather build a space station component, lets call it "habitat" that you load into the cargo bay. You could have say six or more kerbals in it.

We could then make a whole bunch of variants of that module. A crew version, a lab version, a power version, optical bay (for photography), an astrometric research version, etc.

Keep in mind that the KSO cockpit segment will eventually allow more than 4. Eventually I hope to increase that to 6 by opening up the mission deck below the flight deck.

-Note the hatch just below the starboard emergency exit hatch

z0AOPAY.jpg

If I did a lab I'd really want to detail it inside. It would be marvelous if I could get someone with a lot of knowledge regarding KSP. I can animate kerbals actually working on experiments. So anytime you move kerbals to that segment and do research, if you hit IVA you'd see them floating over to the different laboratory experiments and work on their projects.

Edited by helldiver
Link to comment
Share on other sites

What I was talking about was a space lab type module, but with seats. It could even be repurposed as a station module, also, what were you thinking of the interior of the doors being, like radiators or solar, or just blank.

Link to comment
Share on other sites

Correct, I like the module idea more than replacing the cargo bay with a passenger segment.

I'm confused by what you mean by the interior of the doors? Do you mean the inside texture or?

The colors, texture, and 3d shapes based on a lot of factors influenced by the model itself.

The exterior of the modules would probably be hexagonal kind of like the docking module.

Rw1B96M.jpg

The pieces would follow more or less that design aesthetic, except obviously longer. Probably fully octagonal and not asymmetric like that one is. With details around it (cabling, batteries, details). All modules would have emissives to aid in docking and prevent crashing into the thing at full darkness. I'd use emissives for lights instead of real lights as that would be significantly less intensive (and you'd have zero parts involved).

The interior would follow me signature beige accented interior with white/grey lab stations and details.

Again all of that stuff is on hold until we're successfully flying the KSO.

Link to comment
Share on other sites

The exterior of the modules would probably be hexagonal kind of like the docking module.
The exterior of the modules would probably be hexagonal
would probably be hexagonal
be hexagonal
hexagonal

Rw1B96M.jpg

lol

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...