nli2work

B9 HX... 5x5 blocks SpaceY; up to 7.5m BDB; up to 7.5 or 10m? KW; up to 5m IIRC? What's largest in space plane department? OPT? Nertea has something too IIRC? What else am I missing?

"so ok if you want to travel diagonally but useless otherwise" But wait! this makes it useful for Mecanum wheels! used with infernal robotics could make a agile utility rover for crowded land bases.

I don't think 1.1 will bring huge differences for wheels... from Unity docs and the last release of Unity 5.3 the wheel collider isn't very different from Unity 4. Real improvements are likely deep in the physics code that affect the behaviour and not have much to do with how we set up the game assets.

The shock absorbers are under the shroud, won't be seen much, saves time in texturing and baking. about 0.3m taller than the Mainsail. The whole affair under the shroud travels up ~0.3m for the pulse anim. I saved the stubs and round core... if I have time I can turn it into a reactor

full list of layers. http://wiki.kerbalspaceprogram.com/wiki/API:Layers That looks cool! didn't expect the copola internal to fit. Yea sure, I'll put the blank Internal up if you want to make custom setups.

added Camera Component in Unity before export? don't add camera component in Unity, just place a transform with orientation you want. in the INTERNAL config MODULE { name = InternalSeat seatTransformName = Seat2 portraitCameraName = [your transform name] allowCrewHelmet = false kerbalEyeOffset = 0, 0.05, 0 } Other things to check, you probably already did, Kerbals layer is #16. maybe try lower case as per wiki. Can't remember my setup at home at the moment. unlikely but flipped normals?

Ah.. I see. very intersting! I'll make the changes.

You think all that stuff would be exposed all the time? Seems unlikely. I combined these three bits for the 3 sections... top section the fusion core Linear driver section, injects the metal foil over plasma, compress and push it into expander expander bell (I know that's a detector, but it looks better than a cone with rings round the outside)

That's correct MM syntax far as I know. that tells MM to modify the Part, when (and only when) KAS.dll is loaded, with the parameters inside the curly brackets. The modifier parameters adds the model, and associated KAS modules to make it work. As far as I have tested with a variety of setups here it works as expected... a game with 6 or 7 plugins; 0 mods; KSPI-E only. Removing KAS should remove the winch. Otherways I could do this is just put them into individual parts... that ups the part count, kind of defeats the purpose of combining them during game load. Or I can split the configs into separate files that load multiple variants as individual parts... that would be more or less free as far as computer resources cost, but can add to part list clutter in VAB/SPH especially if you have a lot of part mods running.

that was a texturing exercise to learn new software... 5m end caps and 1.5m diameter center column that holds Monoprop. RCS on both ends. I thought it'd be too big to be useful, but it fits inside the 3.75m fairing. It'd probably make a good piece for space station. I'll upload it later this week.

Yea the first pic is how I originally designed the adaptor... something that fit around the command pod to give it forward stack node. B9 has similar part, where I got the idea from, but that one is for 2.5m parts. I didn't expect the grappler to fit inside the adaptor. the grappler was built to reach around the command pod originally. If you were pulling medium to large asteroids around, the grappler is better, much stronger RCS and SAS. If just moving moderate sized things around orbit, the adaptor is more fitting. You could always stick the stock grappler on the front of the adaptor for variety. unfortunately game doesn't allow more than 1 docking module on a part; and it can't be on the same part with a command or grapple module. Aha! I didn't realize stock docking nodes now support more than one type... which means the adaptor's docking clamp can become a universal docking port! that'll be in the next update too.

PBR doesn't make it easier, it's just a unified way of doing the render calculations. For the artist it actually makes it harder, there're more texture maps to wrangle, more time to make high poly base models and bake masks and base maps. Tools are getting much better, but things still take more time and effort for current gen graphics. Hope the new official x64 is stable enough to game on, and the new load on demand works out, cuz PBR and 2x to 4x 2k/4k texture maps on half to all the parts is going to make the current ram problem look like childs play... and KSP will be a much bigger download.

can you give me list of the mods you are running? want to see if I can replicate the situation here.

ok, sounds like that'll work out well. I can set up a looping pulse anim and you just cycle it at some rate based om throttle in KSPI-E

Yeah, the command modules don't have front stack nodes. I figured the most obvious way to use the adaptor is mounting the command module in the middle stack node. that way you get a bottom/top stack node, and a forward docking node in 2 parts. plus RCS and Mono. Sticking some batteries/RTGs in the service bay can up the EC charge. The structural pillars gives some radial attachment areas as well. Attaching a docking port at the rear gives you a pretty versatile and compact tug in just 3 parts. If going the absolute minimum route you can use the drone core + docking port. I'm sure there're many more creative ways to use it, like Enceo's done.

We can do it w/ FXAnimateThrottle... the shock absorbers would become compressed more from increased throttle. There would be no back/forth movement. You might try modifying the stock FXAnimateThrottle so it loops the throttle animation at different rates instead of sliding from 0 to max frame#. I think the nuke pulse engine mod just timed an animation with each pulse? the animation can be slowed down or sped up to match the pulse rate... or possibly two nodes that you lerp the free moving section to/from, along the line of thrust. little more coding, but won't need special animation. either way it'll need some special code. FX would have to be timed as well.

Thanks, will be fixed next update. Yeah, the attached models are added with Model node; if you want the vanilla pod all the time, just delete the widget blocks. same for the drone core.

hm... that's interesting... check the database/assemblies in ALT-12 while at space center, see if KAS.dll is loaded. To remove the winch completely, at the very end of the OrbitalTugPod.cfg there's a section "Start Widgets" with a section starting with @Part[OrbitalTugPod]:NEEDS[KAS]{ stuff }. Delete everything between the curly brackets and that will get rid of the winch, even if you have KAS installed later.

of course, I agree.

the winch will only be there if you have KAS active. KIS will not affect it either way. if you don't have ModuleManager then it'll only be the base model. Updated OP, added KSPI-E Engine config. fixed bug in last version where engine is not available with KSPI-E

attempting to do something inline with zzz's stuff. Mainsail for scale. looks like I missed the shock absorbers... is this thing going to do the pulse action like the video?

Sure, but the internal stuff was broken before 1.0.5. All I'm saying is PartTools could use a little more love relative to the game, 5 updates to the game and 0 updates part tools. Internally it must have been updated at least once or twice since 0.23, or we wouldn't have the issues opening the Internals in 1.0.5 as we do now.

no, but parttools could have been dropped before 1.0.5, bunch of the new Internals are unloadable with the old one, just crashes Unity. whatever results from new parttools has to work in the current version of the game otherwise they can't use it internally. waiting till 1.1 just seems a very arbitrary choice.

Second!