Cheebsta

Due to popular demand, jetpacks have become a usable part that will come into play in accessing certain areas rather than a quest only item. This "release" should be considered somewhat experimental. Compromises have been made intentionally between realism, fun, and functionality, and we want to see how we've been doing across a wider audience. Important: Another few reasons we consider this release experimental: - Sometimes you may not be able to save or leave the scene cleanly on a hard landing. - If the Kerbal is knocked from the seat during a hard landing you may lose control of the Kerbal. - If the jetpack is destroyed while throttled up the game will complain about the throttle being on when you try to leave the scene. If you don't crash you should be okay, save before launching the pack itself, or throttle down and quicksave before attempting to crash...err, land... so not much progress is lost should one of these things occur. Also, the lights are pretty new, not working quite as I expected them to, and may not have the best possible placement. The winged pack is also missing any physical indicator the lights are on there. The three powered packs do have them though. On the rocket pack it faces backwards. That said, on to the Jetpacks: Available on Spaceport: Kerbolquest Jetpacks And Mediafire: KQJetpacks.zip Use Notes General All packs have a built in decoupler on their surface attach point. You can right click on the pack to activate the engine or decoupler separately, using spacebar activates both at the same time. SAS is available on all packs, with reaction wheels to control, so they steer pretty easily. Keeping SAS on is highly recommended. Select "Control From Here" in the packs right click menu to get the Navball oriented correctly. Vertical and winged packs require oxygen to function. The rocket pack is best used in space and low gravity. It is able to dock with Jr. Docking Ports with the clamp on its back side. Velocity Controller Once the pack is in flight holding spacebar also does... something... on each pack. - For the glider it simulates air brakes. - On the vertical pack, diverted exhaust is used to slow lateral velocity (requires running engine). - The rocket pack uses the RCS system for 6 way stability control. - The winged pack has thrusters to aid in slowing forward motion during vertical landings. The amount of thrust used by this system is automatically calculated, up to a maximum amount that varies from pack to pack, to control velocity. Hover System Self powered packs also contain a hover control system. To use this system press [End] to activate. Once activated use [Page Up] and [Page Down], at full throttle, to dial in an exact vertical speed. [Home] sets vertical speed to zero. Combined with the lateral velocity controller landing these little things becomes a cinch, and you should be able to explore places you'd have much more trouble reaching with a full size vehicle. Stay tuned for updates. Contains "jetpacks.dll" which is a combination of: https://github.com/HubsElectrical/KerbTownExtensions/blob/master/KerbTownExtension/KerbolQuestPack.cs Author: Razchek https://github.com/HubsElectrical/KerbTownExtensions/blob/master/KerbTownExtension/KerbTownModules/PartModules/KTengineHover.cs https://github.com/HubsElectrical/KerbTownExtensions/blob/master/KerbTownExtension/KerbTownModules/PartModules/KTvelocityController.cs Author: Snjo Packaged for convenience during installation. Consult with their respective authors about licensing information in regards to this plugin as usage permissions may vary, and are subject to change after this posting.

I always enjoy watching people who know nothing about code engage in discussions about code, lol. Good luck with this project, would be kind of neat to have KSP as a LAN option.

Unity should split the Ngon face automatically, same as quads.

I was kind of worried even that wouldn't work, lol. Does it completely destroy the illusion of 4 separate legs? That is what I was worried about mainly. I don't think there is a way to stop the wobble. My packs are just using a simple box and still do that, unless you set them down kinda hard, and then I think you just don't see it. @Disarming, part colliders pretty much have to be convex. They "work" when they're not, but not very well, and they're a much bigger hit performance wise.

That is definitely weird then. Almost this same thing just happened to me two days ago on one of my own textures after I mapped it for specularity. The black parts in game were the fully transparent sections of the alpha channel.

In the window that shows Layers is a Channels tab. Turn off visibility for Red, Green, and Blue so you can look at just the alpha. Is it greyscale, or black and transparent?

Look in GIMP at the alpha channel itself. Fully transparent on there can render black in game if using a specular shader.

I am thinking this idea may make it land a little funny, but if you don't mind yet another test, try animating a single large collider along with the legs rather than individual colliders for each leg just to see if it makes a difference. I begin to wonder if the issue is the 4 colliders "pushing against each other", for lack of a more descriptive phrase, and causing a pincher effect holding you to the the terrain.

ATTN: We have some amazing talent in the coding and geometry departments, but we really need a dedicated texture artist or two. There are a wide range of things to be painted; structural, organic, high tech, natural, a little bit of everything really. We could use some more help in this department as the workload is currently pretty high for those doing it (most are also modelling at the same time). Prior experience is a massive plus, though not really a requirement. It is imperative that you show some work you've actually done though, but said work doesn't have to be a texture. Basically, we don't want to end up having to teach someone how to use Photoshop or GIMP, but do not mind familiarizing someone with working on UV mapped images. UV mapping is also not something you have to worry about doing, we'll get them to you in whatever way works best for how you're gonna paint them, so you'll just have to paint and consult on how you'd like the UV laid out or changed. Please contact HoY or myself via PM if interested, or even just right here in the thread is fine too. Thanks.

Hmm, how about... Does the thrust collide with the foot collider? I didn't think this mattered if they are part of the same part, but maybe something with the animation module is changing that?

No problem. PS; As long as any mesh colliders you use have the "Convex" option checked they'll work. It is "better" to use a primitive if at all possible though. The game seems to handle primitives a lot more carefully than mesh, ie, a box collider will rarely get stuck in the ground while mesh colliders are notorious for doing so. The whole process is really just a lot of playing around to get to what works best for a given part, so you're on the right track there.

Are you using mesh colliders for the landing legs? Try a sideways capsule, or even just a box. This is a great looking part btw. Would love to see more multipurpose service extensions to simplify lander builds. No one really goes out of their way to abuse modules in the way they should be. If you've seen the KerbolQuest thread, that jetpack is actually my baby, and I will say, it uses just about every module in the game on that one part, haha.

You *can* skip Unity via .dae files, but most things don't work very well that way, especially engines. Check out some of the Unity tutorials, it is very easy to use, and free. What you are missing is a "thrustTransform" to tell the game where, and in which direction, it should apply the thrust of the engine.

The log will tell you flat out if it "crashed" on the mu or cfg file, no need to guess. That said, the cfg is the problem from what I see. Look at the existing files from Squad. If you're making a new tank you can pretty much copy an existing file and then just change the part name and tweak whatever other settings you want to fit your part. At the very least this should help you find where you've gone wrong thus far. Many tutorials contain some fairly dated information. Also, you do not need to match cfg name to Unity name for the part itself. "name=something" just defines the name KSP will use internally, however, that name must be unique among all loaded parts or things get a little screwy. You do have to match the "mesh=something.mu" line to whatever you entered as the name for the exported model in Unity though, and if you add thrust transforms, seat pivots, intakes, or other things like that, their names must match in the config to what they are in Unity.

Afaik the particle exporter is just broken in Part Tools, or at least, that's what I have been told by someone I trust to know the answer (Razchek). Unity automatically applies your modifiers coming out of Blender, so you can always keep your modifier stack un-applied for future tweaking. I dunno about other programs though. Another way to get around over smoothing is to break the mesh up into pieces. Separated edges will render sharp, and then you can use a different edge split angle for each "group" that way.

It was nice of you to credit Razchek for the code you're using to actually get this into the game or the post you copied to edit your OP. >.>

Not very difficult to keep things flat if you have control of the generator. Start with a smooth sphere and just exclude a region. The larger problem I am finding with KT mesh interiors is that you don't stay inside if you leave and come back. I keep getting ejected onto the roof directly above where I was standing. I would assume "PutToGround" has something to do with this, but haven't yet pestered Raz to look into it, and now he's playing Blacklist, so dead to the world, lol.

Rather than make the wedge so smoothly angled, make it more steep, with a square notch kind of key at the "bottom", or top of male end, and make the male end 10-20% bigger than it looks like it needs to be. That will get you as close as you're going to get using a collider, or cause it to explode instantly every time, lol. Also... it seems really weird there wouldn't be an inbuilt vessel rotation function to take into account SAS torque and all of that.

Usually normal map intensity is controlled from the software that made the normal map, or in the gradients you use when making them. If you're just turning RGB images into normal maps expect them to look a little crappy without some touching up.

Couldn't a plugin detect ports a bit farther away and apply rotational force as needed to the incoming port/vessel?

I didn't see you mention anything about Unity. There are a couple threads around here on what you need to do with it, very simple, very much required. If you were already using it, what did the mesh look like in there?

Okay, thanks for the link. I will try it today using numbers more along those lines and see what happens. Hopefully that also clears up the changing sizes thing in the VAB.

The original part is modeled at 80cm, which ends up 1m if I don't use rescale at all (Default seems to be 1.25?). All 3 sizes are set to scale = 1.0, 1.0, 1.0; is that what I want, or are you saying I have to play around with a combination of the two? I am also just going to make the original bigger. Main thing I am trying to do is just use the one model and set of textures rather than 3 like I had been before. It sounds kind of like I'd be better off just doing what I had done before and altering scale then calculating the new nodes myself. Not a big deal, but cuts down on how lazy I can be if I decide I want a bigger or smaller part later, lol. Thanks.

I know there was some weirdness with using these in the past, but I had previously worked it out for a couple parts I use/made. After this last update I've run into an interesting problem. The part is question is cylindrical and in 3 sizes. Before I used separate models, textures, and configs. In those configs I ended up using plain scale and left rescaleFactor alone. This still works, but I was trying to consolidate everything down into a single folder/file. For ease of use I figured I would try using rescaleFactor to move the nodes around, and that's where I ran into troubles. When I first select a part from the menu it appears in its "raw" size. IE a standard cylinder modeled at 80cm, which would normally be 1m in game, appears 80cm in game. However, if I leave the VAB and return the part shows at the proper size. The workaround is just to do it how I was before with scale... But I am kind of curious if there is a way to get around this problem and still use rescaleFactor?

Thank you for the speedy fix Easy to follow, and very good feature. That should make interaction a cinch. Edit: On latest I am pulling a Null Reference Exception in the log now going out to Spaceport view with a static placed in the vicinity. Still working out more specifics, but... It looks really cool. Leaving this for the cool picture, but disregard the error, fixed by erasing the old instances out of the configs. Bonus extra awesome: They show up on .21 Spaceport view!