Jump to content

Kerbin Mini Shuttle

helldiver

By helldiver
in KSP1 Mod Development

 Share

Recommended Posts

ZRM

ZRM

Posted
Posted
Would it be somehow possible to replace the stock navball with yours for other capsules?

Yes, it should be. The stock navball is a prop, and is instantiated in a cockpit via settings in the config file for the cockpit. So you could edit the config to remove the stock navball and add another one. Helldiver would have to provide a suitable model for the navball holder so that the navball appears with the same visibility as the original one. You could also use a similar technique to add standalone MFD units to stock cockpits.

Alternatively you could just use my yet-to-be-released material overriding plugin I have been developing for the shuttle to make the navball emissive and use Helldiver's textures. In this case the model would be the same one as the stock navball.

Link to comment
Share on other sites
helldiver

helldiver

Posted
  • Author
Posted
Would it be somehow possible to replace the stock navball with yours for other capsules?

My navball doesn't really change anything from the original, aside from the new texture. As ZRM said you could simply replace the stock textures with the ones in this project.

In regards to using the actual Navball instrument; Not currently. Definitely once we have everything going I can split off the instrument itself (the Nav ball holder is part of Analog_guages mesh and we could package it so someone could use it to replace the stock one.

Link to comment
Share on other sites
helldiver

helldiver

Posted
  • Author
Posted (edited)

This man is beyond incredible.

Just got this today during our regular dev updates.

Keep in mind this is still WIP and ZRM is still bare-bones on flight data and such.

-ZRM's WIP

OK3sVM1.jpg

-Please do not remind us that the nose cone and LRBs are missing (or V-tail configuration). Each part has to be tested and possibly programmed to ensure it functions properly. The more ZRM works on this the deeper the rabbit hole has gotten.

Edited by helldiver
Link to comment
Share on other sites
XAndrius

XAndrius

Posted
Posted (edited)
This man is beyond incredible.

Just got this today during our regular dev updates.

Keep in mind this is still WIP and ZRM is still bare-bones on flight data and such.

-ZRM's WIP

OK3sVM1.jpg

-Please do not remind us that the nose cone and LRBs are missing (or V-tail configuration). Each part has to be tested and possibly programmed to ensure it functions properly. The more ZRM works on this the deeper the rabbit hole has gotten.

Wow, it looks really amazing in-game. Can't wait to fly it. It's really unfortunate that my computer's Intel HD4000 graphics will not be able to handle the full-res textures though.

Edited by XAndrius
Link to comment
Share on other sites
ZRM

ZRM

Posted
Posted
Is a decoupler built into the EFT? I do not see a stock decoupler in the picture.

Yes. I'm also performing a feasibility test of a custom decoupler module that actually attaches to the shuttle at all 3 support points. Currently struts are required next to the lower support points due to the inability of creating cyclic attachment graphs in the VAB/SPH.

Link to comment
Share on other sites
TimothyC

TimothyC

Posted
Posted
Yes. I'm also performing a feasibility test of a custom decoupler module that actually attaches to the shuttle at all 3 support points. Currently struts are required next to the lower support points due to the inability of creating cyclic attachment graphs in the VAB/SPH.

I know it hasn't been developed for a *long* time, but you might want to look into Tosh's old seaplane float mod, I know that it was

, so it should help?
Link to comment
Share on other sites
ZRM

ZRM

Posted
Posted
I know it hasn't been developed for a *long* time, but you might want to look into Tosh's old seaplane float mod, I know that it was
, so it should help?

Thanks for that link. Looking at it, it looks like it uses exactly the same technique I am testing, only in a very limited form. In reality invisible auto-struts are quite simple code-wise. Why Squad haven't used similar techniques already to solve the wobbly rocket problem, I don't know. Once I have this working properly for the decoupler using raycasts to determine strut locations, extending this to make much more realistic and rigid rocket part stacking as well as to allow cyclical vessel structures (such as several decouplers on one layer) should be trivial.

Link to comment
Share on other sites
helldiver

helldiver

Posted
  • Author
Posted (edited)

ZRM, you also have automatic fuel feeding without a KSP fuel line?

Update:

-I just sent off some additional support materials needed. That included the updated Nav ball and components, engine emissives as well.

-I ran out of time today since I wanted to marathon the MFD components, will try and get them done throughout the week, one mfd at a time (starting with ADI and so on)

Just wanted to clear up guys that we are not adding anything to the project that deviates from our original goals. The only things I added was the lift vehicle and this was because as ZRM discovered, we needed to do some custom work in order to get it all functioning correctly.

Any work that may seem like "bloat" is actually stuff we discovered that was either missing, bugged, or required for the project. Most of the additional technical work is on ZRM's side as he discovered issues with KSP, including bugs, incomplete components and so on that needed to be cleaned up, added, or repaired :D

Edited by helldiver
Link to comment
Share on other sites
Devo

Devo

Posted
Posted
It's because the stock navball prop includes an annoying holder for the navball, and there is no way of embedding the prop into the instrument panel without that holder protruding.
I think that's another reason why this looks so promising, if you guy's come across an issue its not a matter of "oh well, we'll have to do it that way I guess", instead it's "stuff that, lets just make our own".If this doesnt go into KSP as a stock item they are nuts.
Link to comment
Share on other sites
ZRM

ZRM

Posted
Posted
ZRM, you also have automatic fuel feeding without a KSP fuel line?

Update:

-I just sent off some additional support materials needed. That included the updated Nav ball and components, engine emissives as well.

-I ran out of time today since I wanted to marathon the MFD components, will try and get them done throughout the week, one mfd at a time (starting with ADI and so on)

Yes, fuel flow seems to be working fine. I didn't even do anything special to get that to work.

As soon as you have all of the components for an MFD display at a state where the structure (i.e. hierarchy of graphical parts) is final (but not necessarily the layout), and every part is usable, please send them to me so I can work on the code required ahead of time. It does not matter if the layout or sizes are not exactly right or the graphics are placeholder, as long as all of the required components are there. That way there can be a bit more of a "pipeline" of productivity and the final MFDs can be set up nearly as quickly as you finish them.

Link to comment
Share on other sites
M.Wolfy

M.Wolfy

Posted
Posted
ERMERGERD! FLEGHT TERSTING FAZE!!!!!!!!!!!!!!!!!!!!!!!!!! Ok, I'm back, but I cant wait for this, i can already hear the rocket fuel turbopumps startng. IT HAS BEGUN!

RUSHED POST! also do the orbitz OMS engines require that 15 degree or any degree at all snaz? or is it just straight? (because i don't like doing that 15 degree stuff :L)

Link to comment
Share on other sites
stupid_chris

stupid_chris

Posted
Posted (edited)
RUSHED POST! also do the orbitz OMS engines require that 15 degree or any degree at all snaz? or is it just straight? (because i don't like doing that 15 degree stuff :L)

I'm pretty sure they'll need to be angled at 15deg with TouhouTorpedo's thurst vector engine plugin to work I believe, and I also think you'll need to use ZRM's thrust balancer to prevent the whole thing to attain firework form.

Misread OMS, heh. The above stands for the SSMEs. The OMS are at least going to need ZRM's mod. From what I read they'll have a thrust vectorer too, but depending on the gimbal range you might not need it.

Edited by stupid_chris
Link to comment
Share on other sites
ZRM

ZRM

Posted
Posted
The shuttle looks great in the air. Keep up the great work. I look forward to seeing it in space!

Well, if you go back a few pages, you can see screenshots from inside the cockpit in space.

RUSHED POST! also do the orbitz OMS engines require that 15 degree or any degree at all snaz? or is it just straight? (because i don't like doing that 15 degree stuff :L)

Well, the current plan is to make it so that the gimbal range on both engines is purely there to change attitude and counter any changes in the COM due to fuel flow. It should not be used just to get the engines pointing roughly at the COM. That is the job of the engine pivot hinges. Luckily it will only be an action key or two to get the engines pointing in the right direction, since pivot presets can be written into the config file. Making use of the pivots like this ensures that the gimbals have the approximately the same freedom of movement in both negative and positive pitch directions for attitude changes.

How many parts is the shuttle itslef comprised of, and do they use a node connection system if I may ask?

Or is it all one part?

If you can bear to trawl back through this thread, you will find that the shuttle is split into several parts, all attached by the normal attachment node system (for the time being - I am working on an improved system). The shuttle itself comprises of a maximum of 20 parts, if you include the avionics in the nose cone and the docking adapter. The reason that it is split into so many parts is partially due to artificial limitations needlessly imposed by KSP, and also partly due to some inaccurate advice helldiver received early on in the modelling process. It also helps to have the shuttle split into several parts when you consider the variety of status information and buttons you will find in the context menus. If it was one part that context menu would be very long, and some of the menu items would be identical due to there being more than one of some modules on the part (such as the engines).

If necessary I can try welding parts together at a later date. That is something to consider after the first release, however.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...