TouhouTorpedo

I've ran out of time tonight to be able to do it and wouldn't know exactly which parts to highlight. It should be reasonably self explanatory for someone with a little Unity experience, but if there are specific areas that prove troublesome I may add some images.

I got asked a few questions about IVA transforms today, and that led me to thinking about IVA and checking things enough that I decided might as well make an IVA tutorial finally, since a few others have gone dead now. TT's IVA cockpit tutorial V1 A somewhat rushed IVA cockpit tutorial without the basic Unity stuff. I've also included the external work like ladder and hatch since it's pretty closely related and almost always going to be there in the same projects. Where to start? ------------------------------------- You need to export three different things here. An external model, an internal model, and the props internal cfg. I usually make three blank gameobjects, center them, and build from those, one for each export. Put PartTools on the internal and external, and Proptools on the internal props transform. also, I recommend you've at least made a fuel tank or engine or something basic in Unity first, so you've got a vague idea what you're doing. Directions things face -------------------------------------- the Kerbal transform Z faces forward, Y faces upward. for external model Z faces up, Y faces forward. For the internal model, Y faces up, Z faces BACKWARD. for props they are a bit arkward. They all work a little different so you'll just have to try and play it by ear as I don't remember every individual ones direction. Note axis indicators all have the same orientation, so some will need to be placed with their transforms at 90 degrees to the others. Important note on Scales -------------------------- you must MUST work to reScaleFactor 1. If you don't, then it won't line up and you'll just have a big headache. Even if you think you'll be clever and resize the internal model 1.25 in Unity. It knows you're being a smartass and it'll make you pay dearly, trust me I tried. The Layers you need to use and not get wrong for everything in IVA -------------------------------------- 16 - Kerbals this layer is used for placing the Kerbals transforms, and anything that you want visible in IVA AND the Kerbal portrait cameras. Place any box colliders with IsTrigger set TRUE for areas you can double click to change camera view (these may work on 20-internal space too but I haven't tried) 20 - Internal Space this layer is used for placing anything that you want visible in IVA but NOT the Kerbal portrait cameras. The external model of the MK3 cockpit is in this layer in the MK3 IVA mod for instance, so it doesn't block the portrait camera views, but is visible on the external cameras or to Kerbals. How to add IVA cameras -------------------------------------- in the cfg use "InternalCameraSwitch". Set colliderTransformName to whatever you called it in Layer 16, and set cameraTransformName to the same name as an empty transform in Layer 16. It might not need to be in that layer - thats just what I used. in those transforms Z faces forward, Y faces up. The Layers AND TAGS you need to use and not get wrong for everything in external model -------------------------------------- Default - Everything Kerbals won't use. 21 - Part Triggers Anything you want to use as a Ladder or an Airlock MUST have this set as its layer. But these must also have Tags defined. Tags to also not get wrong, these are added the same place as Layers by clicking to the right on Element 0: -------------- Airlock Ladder Adding Airlocks and Ladders on your EXTERNAL MODEL ------------------------------------------ Use a BOX COLLIDER in a game object (name not important) X and Z size I use is about 0.5 but vary it as neccesary. A shallow hatch may be more to your taste if you get it working. Hatches Box colliders typically MUST overlap the collider for the model, and the models collider must overlap the ORIGIN of the model (0,0,0). You might get away with either of these but if you get "Hatch obstructed" bug, not following those is probably the cause. Kerbals face toward the Z axis and climb up the Y axis. It is a very good idea to have a Ladder box collider overlapping the Airlock Box Collider, Typically in the same location. Be sure they are in LAYER 21 Part Triggers, and Ladders are set to "Ladder" Tag, and Airlocks to "Airlock" Tag. Another thing, move the TRANSFORM, NOT THE BOX COLLIDER CENTER. As that'll bug out to hell and just shoot off kerbals into space or inside your model itself. Center must be left as 0,0,0. For bent ladders just overlap the colliders a little. For climbing over a 90 degree bend, use multiple ladder colliders, so the Kerbal goes over the angle in steps. 3 colliders at 45 degrees should work fine though. Adding your props ------------------------------ Props are added using proptools. Its pretty self explanatory as you use it to be honest. But the old versions were really buggy and needed you to manually update the exported cfg file to get them working right. It used to export radar altimeter and the axis indicators wrong, so be careful with those and compare them to stock cockpit internal cfg's. This may have been fixed in the newest version. I always combine the PropConfig.cfg that is exported with the Internal.cfg file, but there is a lot of ways to get these into the model. Firespitter for instance adds these in the part.cfg! Just check out other implementations to find a way you like best. Final note: ------------------------------------- Let me know somehow if anything is wrong and I'll look into updating this. I'll hold no responsibility for time spent head butting walls, melting GPU's and cursing Unity's name. You decided to indulge in this torture yourself!

Last I heard Module Manager is not compatible. Uninstall that and it should work.

Wrong, its not a limitation. If that was true, then struts wouldn't even be possible. It'd be relatively simple to say, add three virtual point attachments around that single attachment node used now, so that each of these three virtual attachments can resist torque properly through the rocket. Its actually something I'm considering as a mod to look into, but because I'm not devving the game engine and would have to mod every single stock config file to add it in, or shoehorn another module that adds this module to every part added automatically, it'd be a big undertaking from a modders perpective. But if the game engine was changed so attachment is done at 4 instead of 3 points, (central shown node, Y axis displaced point, Z axis displaced point, X axis displaced point) that wouldn't be too complex and a massive improvement. Honestly, I challenge one of the devs to add this and see how it behaves. The Strut code could be shoehorned into the attachment node code to easy make this possible and bring it into the next version.

If we're gonna talk making the game more accessible, I think sorting out the single node attachment behaviour is what needs doing next. Because it frankly doesn't work on a bigger scale. Strutting helps sure, but its a very tricky thing to get right, and means big rockets aren't very accessible. When you have made a big rocket that works, Typically its a mess of structural elements and girders with more resemblance to architecture than a rocket. I hope this is something that gets looked into very soon. Its absolutely neccesary if they are ever to exceed 2.5m diameter parts anyway, As anyone who has tried 3.75m mod parts would know - they wobble terribly.

In that case I honestly don't understand what might have caused the problem. It sounds like you're using the right controls. Check the plugins folder for me, is there one single multiwheels file, or loads of them? (Do you have TTGraphicsFlip or something similar, for instance?) Also, check the CFG files and their max torque values for the "_m" wheels.

Like Gristle said, it sounds like you aren't running Modularwheels 0.5 but actually Modularwheels 0.6. And that added the requirement of putting engines in place. the RCS and Electric modular engines are a good starting point, as you haven't got to worry about routing fuel lines for them.

To be honest, I wish it didn't have FAR support. There would be a lot more that could be done with this if it didn't have to depend on the center of lift being in the dead center of the wing root, which has to be done for FAR to work. But it means the stock behavior is not as good as it could be.

A likely cause of the faulty resource consumption is either root part having an unusual transform (some girder types have the wrong transforms, I think they are rotated somehow else? possibly the cfg, honestly never checked) or because of a Unity wheelcollider glitch which I've got no control over. If certain wheels have a greater load, say a rear wheel drive car with all the load on the rear wheels, it'll be faster than a front wheel drive with all the load on the rear wheels. The way I've distributed power to each wheel is intended to eliviate this problem somewhat, but can't entirely solve it. This problem is why a very heavy stock wheeled vehicle is strangely similar in speed to a very light one for the same power consumption, which I've coded to try and prevent occuring.

Ah but a key point you're all missing here, although I admit this thread is about n-body, not pertubation. n-body may not be all that feasible due to timewarp and error, but there is another option. Pertubation is predictable and has plenty of defining equations, and imo has as much fun potential as n-body physics, since you can still make some really cool things happen, like sun sync orbits, gradual orbital decay, orbit eccentricity changes under sunlight influence, that sorta thing. And they're so small changes, you could easily have some kind of option you can leave on in a vessel to maintain orbit while you aren't on it and timewarping. Since the behaviors are predictable, it should be possible to have in the information display how long the life of the mission is expected to be before de-orbit, unless either automaintained or in a situation where it would not decay into a body. It'd also make what altitude you use actually mean something with regards to how long a mission can realistically last, and how hard it'd be to maintain.

I have no idea how I lived without this for so long. My biggest pet hate (not being able to make cool rovers in SPH then stick them on VAB rockets) is finally solved without messing around copying and editing files. Top mod.

Interesting idea I hadn't considered. I don't asparagus out of principle, but the idea of structural beams to take the primary load instead is an interesting one that could be applied to a normal rocket if well thought out. I normally just do big tall rocket with beams outside, but that has limits. I'll give a structural core instead a shot next time.

funny you should mention the other thread, I found that after and answered just that very concern you have there in that one. So short ver - vessels if they have sufficient RCS/liquidfuel will stay in the orbit if you enable a certain mode when away from them. If said RCS/liquidfuel runs out, the vessel will begin to drift. Something like Kerbal Alarm Clock could be used to warn of a vessel being low or out of station keeping resources, or if the orbit has reached a critical level (atmospheric contact, <10km, etc)

KSP already simulates the trajectory from the gravity influence directly when in off-rails mode, hence it is possible to affect trajectory just by turning your craft under reaction wheels, as its a little too sensetive. Adding in another gravity source would be no less taxing than adding one extra engine on a rocket, at least while off-rails. (<5x timewarp)

Personally I'd like to see that kind of thing, though it would imply changes to the game engine being neccesary to make pertubation playable. When higher levels of automation are available, adding pertubation would actually improve the gameplay quite a bit, if unfocused objects had their orbit control system simulated at a lower level, so they are slowly bleeding off RCS / Fuel / Power while their missions procede. indeed it'd need more processing power at higher warp, than as things are now, but they have said automation is coming eventually. If thats true, and things are going to happen in the background, some degree of pertubation and management for this might as well be added in my opinion.

It should be fixable, its just not something I've got around to looking into doing. I really should find a way to track suggestions and bugs for my mods, but honestly I don't have much experience with that sorta thing. Anyone got any ideas? I'll consider modifying and updating some mods in the relatively soon future, as I hope to get some free time to do an update to at a minimum the cockpit mod.

Je ne sais pas sur l'url dans KSP. Cependant Je pense que Je sais comment obtenir les positions et rotations de chaque child par rapport au parent. essayer : foreach (Part p in this.part.children){ <une variable Vector3> = p.transform.localPosition; <une variable Quartonion> = p.transform.localRotation; <une variable Vector3> = p.transform.localEulerAngles; } Modifier et essayer ce et laissez-moi savoir. "this.part.children" Je ne essayer pas ... si défective essayer code principal sur une part. J’espère que vous comprendre ... Ce était difficile en français!

That is absolute art, I love it and hope it gets some more attention! (also give us more)

ä½ ä¸Â会åœ止我＠avons-nous un problème maintenant? OK peut-être je vais arrêter. appartement je suis Intermédiaire compétence francais a l’université, mais si je suis honnête je utiliser Google et dictionnaire beaucoup. Je pense que je fais adéquate quand il n'est pas en personne.

Je Parle Chinois aussi. Il n'y a la section Chinois sur KSP... J’espère que Je peux aider ici.

Bonjour, Je suis un moddeur, mais... Je peux le lire français mal.... Je parle plus mal...

What is the cooling tower? Do you mean the control tower?

Why would you not allow ion engines since people could set up long burns, but allow mechjeb (Automatic long burns with LV-N)? Its not like ion engines would even be a undisputable solution to this, since they can't accelerate quite so well. Infact for a large enough return craft they probably aren't going to work well at all, but it seems wrong to limit the creativity here on even attempting to try that.

Thanks! Sounds fantastic, upload some screenshots if you can! (I honestly never finished a shuttle to orbit with it myself lol)

I -think- Taverius's Shuttle Mod might have what you are looking for, but I'm not entirely sure. If you do check it out, let me know. MK3 Cockpit does need tweaking to be compatible. I just hadn't got around to uploading my fixed version yet. The currently uploaded version should work fine but will revert the cockpit to the old type (non reaction wheel). I do have a fixed and tested CFG here that'll run with reaction wheels but just haven't updated the mod yet.