evilC

Epic! Opens up a whole world of possibilities for spaceplanes - now you do not even need to have to design in the capability to circularize.

I have not tried this yet, so apologies if it has been already covered. I wrote an app called UJR that lets you control a virtual joystick (with modifications - eg axis invert, deadzones etc) with a physical joystick. The only issue is that it is unable to hide the physical stick from the game, so when you manipulate the physical stick, games often bind to that instead of the virtual stick. How would this mod work with UJR? The virtual stick should always be stick ID 1 - if this mod sees multiple sticks move when binding, does it prefer the lower ID stick? Anything that I can do to make UJR work well in combination with this mod - please let me know.

MY TIR is packed away for the move at the moment, so I can't test. How does this affect external view? I don't really use IVA, but I would certainly like to be able to use head tracking to look around in 3PV.

The download link is in the original post. The non-animated parts will work with any version of KSP as they do nothing (just structural). The animated parts require firespitter (see note at bottom of OP), so you will need a firespitter DLL that works with the current version of KSP, which you should place in the root of your GameData folder.

That would be a workable solution methinks. Apologies for hijacking your thread, I can quite understand your reluctance to break new ground, but hopefully this may spur someone on to create such a mod. FYI, I already have a mod request thread open here: http://forum.kerbalspaceprogram.com/threads/88380-Editor-tool-Parallel-Perpendicular-struts

+1 for "Bitching Betty". "Pull up" seems a bit out of place in a pod But I guess it is still very early days... How about you check to see if the craft has wings or not, and tailor messages accordingly? Also, may be cool to have maneuver node countdowns? Node in 5.4.3.2.1..Node! And I guess if you gave it a UI you could do "Bingo fuel" announcements? The user sets a min fuel level and betty warns as you approach it? Really nice idea though.

Hi, is there any way this mod could be re-purposed to allow you to set the angle of strutting? As in, allow the user to say "This strut projects out at 90deg perpendicular to the part it attaches to". Seems to me that you have the bit that works out the angles, you would just need some method of manipulating the struts.

Hmm, something is not right. You know how I mentioned before that the parts seemed to chug KSP out? I defo think there is something going on - as the more of your meshes I add together to make one bigger part, the more it chugs KSP and eventually causes crashes. For example, I took the large tube frame and started to extend it by duping in other sections of frame: PART { // --- general parameters --- name = TALLargeCargoFrameTubeLong module = Part author = Talisar // --- asset parameters --- MODEL { model = ModsByTal/Parts/Cargo/Models/TalCargoFrame texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture scale = 1.5, 1.5, 1.5 position = 0.0, 0.0, 0.0 rotation = 0, 0, 0 } MODEL { model = ModsByTal/Parts/Cargo/Models/TalCargoArch texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture scale = 1.5, 1.5, 1.5 position = 0.0, 0.0, 0.0 rotation = 0, 0, 0 } MODEL { model = ModsByTal/Parts/Cargo/Models/TalCargoArch texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture scale = 1.5, 1.5, 1.5 position = 0.0, 0.0, 0.0 rotation = 0, 180, 0 } // Above this point is standard tube. // Add another frame... //Top MODEL { model = ModsByTal/Parts/Cargo/Models/TalCargoFrame texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture scale = 1.5, 1.5, 1.5 position = 0.0, 3.0, 0.0 rotation = 0, 0, 0 } // Works OK until this point. // Add another arch MODEL { model = ModsByTal/Parts/Cargo/Models/TalCargoArch texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture scale = 1.5, 1.5, 1.5 position = 0.0, 3.0, 0.0 rotation = 0, 0, 0 } // Game crashes at this point for me. scale = 1 rescaleFactor = 1 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_attach = 0.00, 0.00, -2.25, 0.0, 0.0, 1.0, 3 node_stack_top = 0.00, 1.50, 0.00, 0.0, 1.0, 0.0, 3 node_stack_bottom = 0.00, -1.50, 0.00, 0.0, -1.0, 0.0, 3 // --- editor parameters --- TechRequired = veryHeavyRocketry entryCost = 68400 cost = 21000 category = Structural subcategory = 0 title = TCS Arched Cargo Frame 6m Semi Tube (Large) manufacturer = Talisar's Cargo Solutions description = A 2.5 meter long structural frame with sufficient inner diameter to store 3.75 meter thick parts inside. This version includes arched support along both sides, creating a fully enclosed space. This part is slightly wider than standard parts and should be used in conjunction with Talisar's Cargo Solutions (Large) Adapters and Seperators. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,1 // --- standard part parameters --- mass = 1.5 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 3 crashTolerance = 5 maxTemp = 2900 fuelCrossFeed = True breakingForce = 10000 breakingTorque = 10000 } So I can add the first "frame" mesh OK, but as soon as I add an arch to that mesh, boom! How I replicate the crash: Fresh copy of KSP, only this mod installed. Start in SPH with a drone core Add this part turn mirror on, snap another pair to the side grab another one of these parts. dragging it around can cause a crash alone, but clicking to attach will definitely crash ksp. Anyone got any ideas? I didnt mess with the attach node locations in this example, but I have tried fiddling with those and got no joy. If you want crash logs or anything, lemme know.

OK, I just realized how all the parts are just the same models assembled in different ways and at different scales. It seems that it would be possible to make the parts I described by making new cfg files. Gonna have a go and see what I come up with.

Install Davon Throttle Control and set the non-VTOL engines to another "Davon Group". There should be a light (red/green) on the TCA icon in the toolbar, to indicate current status.

I gave this pack a try today, a few comments: Seems to work fine except whenever attaching / detaching these parts, KSP can lock up for extended periods. Could we please get the small and large frames in consistent lengths? Certain designs could be way better if the small frames were as long as the largess. Also, it would be really nice to have both in various lengths - ie 1,2,4,8m versions of each. Finally, it could do with some extra internal nodes for cargo carrying. Some way of being able to install items like the "cargo adapter" at an arbitrary point within a frame would be ideal. I also prefer your cargo bay system to the current one I use (B9). The retracting doors make it easy to strut etc around the bays without worrying about clipping. With a bit of work, I think this could be the holy grail for extensible craft. I would love to build spaceplane designs using it - if you built a chassis from the frames, with the appropriate parts you could swap out fuel, cargo and engines very easily without affecting the overall design. Here is my current HL spaceplane Here is roughly what I would want to do using your mod: So ideally some way of being able to arbitrarily fill the frames on each side with fuel without having to pull them apart and insert a cargo plate in the middle would be epic. Even better if we had longer frame sections - this would reduce part count and deformation during warp drastically How about something making a cargo adapter that SRF attaches via it's rim? Also, could we maybe even get frames in mk1 sizes? For example, where I have all those jet engines between the wing, it would be nice to be able to mount all those in frames - that way I could strut the frames to the fuselage, making the chassis even easier to customize. Double frames (As in side-by-side) would be cool too If you would be willing to make the source available, I could maybe have a bash at these additions myself.

Uh oh, I just updated to KSP 0.24.1 mid play-session and now it says mechjeb is incompatible

Hi, been trying to use this mod to automate my spaceplane orbiting, but not much luck so far. Currently I uses MechJeb Smart ASS and set PIT(ch) to 30, Heading to 90 and start the engines. It coasts down the runway and takes off. I tried to replicate this with kOS, but no joy - it crashes and burns Now it does stall a little at the start, but mechjeb handles this fine. kOS however does not keep pulling back on the stick enough and lets the nose gradually dip until it hits the ground. Here is what I have so far: lock throttle to 1. toggle ag4. lock steering to heading( 90, 30 ). wait until altitude > 10000. lock steering to heading( 90, 20 ). wait until altitude > 20000. lock steering to heading( 90, 10 ). I did try setting a manual takeoff like so, but that just veered off the runway... lock steering to heading( 90, 0 ). wait until speed > 150. Any ideas? I guess kOS is not designed for spaceplanes, but any improvements you could make here would be much appreciated as SP orbits can take quite long...

With the advent of First Contract, I have even more need for a VTOL capable plane to collect the science from around kerbin. TCA currently seems inoperable, but to be honest after some tests I did today with this mod and Davon's mod, I think ceding complete control of the VTOL aspect is potentially a simpler way to do it, and your code is already significantly refined in that area. I *love* the directional control thing that draws a red line coming from your control pod - truly a step-change in usability. However, I find the current DTC integration a bit lacking in the usability department, though this is mainly due to the setup involved with DTC. Could you not add a setting to choose which Davon throttle to use, instead of defaulting to throttle 0? I have some experience in KSP mod coding, and glancing at your code, is this line where you set the Davon Throttle ID? If I change that to 1, will it use daven throttle 1 instead? BTW, is that a typo in the docs? By throttle 0 do you mean the default game throttle? DTC starts at 1. Anyway, by defaulting to the first DTC throttle, that means I have to go and set up the jet engine each time in davon - map the controls etc. If you allowed your mod to control davon (and ideally operate the axis via pure function calls - ie no keys needed to be bound in davon), then all I would need to do is set the VTOL engines to davon throttle X each time (a couple of clicks) and I am good to go. As it stands, DTC does not seem to recognize my vjoy stick, so setting it up so that my normal throttle controls the jet engines, and your mod handles VTOL takeoff / landing is problematic. Also, is there maybe some way (via DTC?) we could control the desired vertical velocity with an axis or keys?

Squad need to look at this, I could not work this out on my own. Even going to the Tracking Station, you can see the kerbal in orbit, but "cannot switch to a craft you do not own", despite being 10m from him. Amusingly, the first time I tried one of these missions, I did my speed matching burn too close and the rocket exhaust catapulted the poor kerbal away from me at high velocity!

I really like the idea of the dune buggy bay, but I have a few suggestions... What we really need is a way of being able to detach and reattach the buggy. The FH-CRD-1A seems kind of redundant. What would be better is some kind of extending docking port, so that you can re-attach the buggy with a decent tolerance for how high off the ground the FH-COR-1A is. Also, fitting a docking port to the top of the DR-BDY-1A gets a little ugly. Mainly to do with the way that the clamp-o-tron extends into the body of whatever it is attached to. I tried using the telescopic docking ports from TiberDyne, but they do not extend / retract properly when something is attached. Also they lack variable extension. Could you make the FH-CRD-1A able to move up/down? Also, the way the legs attach on to the FH-COR-1A suffers from usability issues - mainly to do with the fact that you cannot attach by symmetry due to the fact the the sides are not at 45deg angles. Suggest that you fix this by adding a node to each of the side panels. That way, we could attach something like a 1x1 plate, then use v-snap to snap each of the legs to dead center of the 1x1 plate, thus ensuring all legs are perfectly aligned. With your legs, you could add a corresponding node, so you do not need to do the 1x1 plate trick. Cheers, keep up the good work.

I really like the extending docking port, but I have 2 issues with it: 1) It will not retract while something is docked. 2) If you extend it with something docked, it seems to pull a node apart? Also, if you could add action groups so we could have finer control over extension (extend + / -), that would be even better. Coupled with the core dune buggy mod, this would provide a way to attach/detach the buggy, without having to resort to more exotic mods.

Yeah, something I had considered, but it was just a case of working out a mechanism to do it. I did, however, just write UJRC - UJR Companion. This is a library to let you define unlimited shift states (ie button alone does one thing, button + shift_1 = something else, button + shift_2 = another thing.) It is not dependent on UJR, but intended to be used at the same time. UJR handles axis mapping etc, UJRC handles button config. No GUI unfortunately, you have to edit config files manually

Thanks for the update. So the upshot of what you talked about RE: "wonkyness" would mean that TCA would not use those engines for thrust, only maneuvering? (ie a rocket RCS). If so, great! I tried doing such a thing but it did not end well If you are looking to make improvements there, I think there are things that could be done along a similar lines to make jet VTOLs more feasible. Most jet engines do not spin up and down quickly enough and so TCA has problems dealing with this - I was thinking if you could keep a small number of bigger jets spooled up all the time to maintain height, but designate some smaller engines that will fluctuate more rapidly to only control rotations / translations, then things could work a lot smoother. So maybe: "non-wonky" (ie full down) = use this engine for main thrust "partly wonky" (ie diagonal down) = augment thrust but mainly control "totally wonky" (ie side mounted) = control only Also, anything you can do to allow you to switch between horizontal pod and vertical pod (ie use current pod as mentioned above instead of root part), that would be great! This combined with PWB Fuel Balancer to keep your CoM at a designated point is going to be such a killer combo!

I just recently came across PWB fuel balancer that does what I wanted regarding moving fuel to acheive a balanced CoM. Would it maybe be possible to merge this mod with PWB? I really like your "Pump Level" innovation (it has a wider variety of uses), but one mod that combined both techniques would be epic!

Hi, Just seen this mod - I originally used TAC FB, but recently moved to GoodSpeed Pump and was only the other day asking the author to provide the CoM fuctionality that this mod has. However, there are some features of GoodSpeed that I would like to keep ("Pump level" settings) as they are useful in a wider array of situations. Is there any chance you could maybe merge this mod with GoodSpeed pump? AFAIK the latest version of GSP includes code from other contributors, so I am pretty sure the author is open to this. Regarding the different CoM targets - I think what would suffice would be some way to balance on the x/y as most fuel balancers do, but then be able to push CoM up/down on the Z axis by arbitrary amounts. For example, when entering an atmosphere and coming in for a landing, having CoM as "low" as possible is probably desirable: When entering atmos, to help keep the right bit (eg heat shields) facing forwards, and when landing to give you the best chance of the craft not tipping over. For these cases, I do not think presets would be needed - you just need to say "as much below the designated point as possible".

I also used TAC FB, but now prefer Goodspeed as it is much easier to use. Would it be possible to add action group entries for tanks as well? eg "Set Pump Level to X" and "Enable / Disable Balance". It would be extremely useful to be able to change fuel balancing mid-flight. For example, while in space you want CoM central, so RCS etc is more balanced. However, if coming in for a landing, a low CoM is handy to help prevent tipping over. So if you could use action groups to change pump level, scenarios such as this would become a lot easier to manage. The ultimate solution would be some way to have the code able to balance tanks to maintain a given CoM point. Say for example you could right click a tank and say "Current CoM is desired CoM". This would then tell the code that the current position of the CoM marker is where you define the CoM to be in your vessel. The code is then able to balance tanks to position the CoM to where the user specified. Knowing what (little) I know about KSP coding, at least a basic implementation should not be too hard? As a first stage, if we left it up to the user to handle x/y balancing, the code would only need to manage up/down balancing. AFAIK you can tell the Z value of any given tank, so whether the Z position of a tank is above or below the desired CoM point should be all you really need to know - the code could pump from low to high and "walk" the CoM onto target. If you did manage to achieve something like this, it would also be nice to be able to issue a "High CoM" (Puts CoM as high above designated CoM as possible) / "Low CoM" (Opposite) option. I am working on a "WEEBL" (egg-shaped, no way to land it badly, always self-rights) craft and something like this would be awesome to be able to rock it back to an upright position using fuel movement. Whatever, cheers anyway for what you have done so far - I wish you all the best with this mod.

Yeah, KSP is a bit crap in this regard. KSP has no concept of which stick a button is on. In other words, while axis bindings have a stick number and an axis number, button bindings only have a button number but no stick number. So, I am not sure how to help you. I know it is possible to do funky things with KSP and UJR though - my current setup allows me to use an XBOX pad (Normal usage) or a flight stick + throttle (VTOL flying) and switch between the two simply by changing the UJR profile. So while button 1 on my flight stick may do one thing, button 1 on the XBOX pad does something completely different. My biggest advice would be to try to edit the config file (settings.cfg) manually. Using the KSP binding interface is an issue. If you do use the KSP binding interface, use the "quickbind" feature of UJR to press a button on the virtual stick without pressing a button on the physical stick.

Yes, it is work aroundable, but kind of a deal-breaker for me, as it makes the job of balancing (RCS / VTOL) much much harder.

I gave this a whirl today - I have a ship design idea that I would like to explore and this seemed like a suitable mod. It's just a pity that the hollow parts break symmetry. For example, I would like to use "UL Frame Square 2m" for the central spine of the ship, however I can get no symmetry on this part. Perhaps a picture will help: See the detached part - I would like to be able to use symmetry from the other side to attach that section. And more bend parts please! Could we get the "UL Frame Bend 30 2m" part but in the other corridor sizes?