evilC

Preview of new UI Notice the Separate JetFuel and RocketFuel(LF) sliders. Both control the same thing, but when you have a vehicle that has both LFO and Jet fuel tanks, this allows you to have a different fill rate for each. Also note the "Link sliders" option. This allows you to link the LiquidFuel and Oxidizer sliders to keep the correct ratio when you do a partial fill. Loading from both SPH and VAB is now fixed. I upped this DLL to http://evilc.com/files/games/ksp/Launchpad.dll so you can have a play before the next full release.

There is no issue with space in the name. If ships do not appear in the load menu, double check your persistent.sfs file for that save. Is the savegame name in the text file the same as the folder name? I used to reset my persistence file by copying the one from "Default Save". I now realize that was bad

I disagree. The navball was 100% intended for this purpose - that is why you land a rocket by keeping the direction indicator inside the retrograde indicator. The only reason we cannot use this for VTOL craft is because "forwards" is offset at 90deg from the thrust vector, so the pro/retro indicators are out of sight at the top and bottom of the navball. I like the idea of a special display tho

OK, now there is another planned change also: The "spacebuilt part" will be abandoned, and OC will share EL's UI - you will control the building platform, then bring up a menu and select a craft file from there like you were loading it, instead of controlling the ship to be "built" before it is even "built". If it is at all possible, I would also like to create the new craft attached or even "inside" of the building station.

Well, I just spent 12 hours re-working EL and adding a UI. I learned a lot in the process, and now between skykooler and I, I think we have it licked. A full UI to show required resources before building is in and working, and sky is getting to grips with the new ui system as I type by trying to add variable fuel fills. Destruction is a distinct possibility, but I had another idea also. Seeing as we have code for creating craft, surely we could use it to make a "dock". When you "dock", the craft is destroyed and a "dock capacity" is reduced by the mass of the craft. You can then "undock" ships and they are created as they were when you docked. Seeing as it is now looking like EL and Orbital Construction will share the same UI, if we can get it working for one, we can get it working for the other.

Any container which holds the right resource type will work. So if someone made a KASPAR container for RocketParts, it would work.

Yes, this will not change. The rocketparts could also come from an EL facility on the mun, or even ore from the mun to an orbital station which processes the ore and stuff into Rocketparts using EL's processing modules, then assembling using OC.

A new version will be released that is compatible with the Extraplanetary Launchpads mod. This is basically the same idea as OC, but it spawns the ship on the surface of a body. This will mean: SpareParts will change to RocketParts You will require the appropriate amount of fuel to build a ship (may be optional, may allow partial fills) The OC resource containers will be abandoned - RocketPart containers will be standardized with Extraplanetary Launchpads Basically, the next dll patch I release will fork off from Orbital Construction and make OC effectively an extension for Extraplanetary Launchpads. The next version of EL will release when the author has fixed compatibility with Kethane The author of Kethane is looking at altering it to allow people to extend kethane by adding their own resources. So ultimately it is likely to work something like this: Kethane adds kethane as a resource, plus the converter and the gatherers (ie drills) and detectors for that resource. EL adds ore, metal etc and the gatherer and detector parts for those resources. It also configures Kethane to recognise those resources and let the converter unit process them according to paremeters it provides. OC adds an orbital constructor part and a spacebuilt indicator part as now, but that is all. It uses other infrastructure from EL for the parts and hopefully uses EL's routines to decide cost for building a craft. This should place us roughly where KSP is headed as a game. As parts are released officially by squad, I guess we can phase parts of this trifecta out and make the remaining bits compatible - eg when official resources come in, dump the custom ones and hook everything in to those.

oh, so just one resource? All the rocks, fuel etc gets combined before that? Sounds like an easy change.

No. I had a dig and found the problem. Edit: Parts\OC_Small_Cargo\fuelTank.DAE Change the line <init_from>file://W:\GAMES\KSP Silisko Edition\Parts\fuelTank\textures\fueltank_tex.png</init_from> to (Difference in Bold) <init_from>file://W:\GAMES\KSP Silisko Edition\Parts\fuelTank\textures\fueltank_text.png</init_from>

Since the Orbital Construction mod seems orphaned (And not really finished) and I was the last person to release an update for it, I guess it sort of makes me the guardian of the code until the owner shows up. If you need any mods to OC to make it work with this, drop me a line and I can release a DLL patch. Seeing as I release these as byte patches, you would be legally allowed to include my DLL patch with your mod, but not the original DLL.

I would like to see feasible four-point horizontally-oriented VTOL (Osprey style) for non-perfectly balanced craft in KSP At the moment, even if your craft is perfectly balanced it is problematic - the best solution I have found is the Throttle Steering mod - this is capable of setting individual thrust levels per engine and also using control inputs to control these levels to let you steer like RCS. When combined with ASAS and RCS (Not thrusters, just RCS mode being on) it can keep an uneven craft in a stable condition, though it over-corrects some. Personally, I reckon even the level of control that gives is maybe good enough, at least to explore some concepts. However, there is one minor niggle: When using a forward-facing, plane style craft (Say with the B9 VTOL engines that can rotate), the retrograde/prograde vectors are going to be up and down, not forward and back. So if coming in for a VTOL landing with a dropship, you either have to land vertically like a rocket, eyeball it or switch control to an up-facing pod, but this then changes the control style, ruining the experience. Now I can code to a degree, although my only experience with ksp coding was fixing the orbital construction mod, however the problem was not version compatibility, it was optimization (calculating values every tick not using static var) and usability issues (author didn't seem to grasp quirky nature of UI coding) so whilst I am lacking in ksp experience and maths knowledge, I feel that with a little outside experience I can put something together, or assist someone else putting it together by doing some of the grunt work. For now, I am just proposing taking whatever we can from wherever we can to cobble some ideas together. If we get to a point where we feel a release is merited, then we may have to obtain permission from authors to redistribute or create our own assets, but for now using Throttle Steering and the B9 VTOL engines as a testbed seem like the smart move. So all that leaves for the moment is the navball mod. I reckon for someone with the right experience, some basic code that just moves the prograde/retrograde markers by 90deg (or inserts some other marker) would be a 5 min job. Slightly more advanced would be to make the icon follow the current orientation of the B9 VTOL engines. However, if I were provided with a function to insert an icon at an (x) degree offset to the actual prograde as a solution to the previous problem, I could possibly rig this up myself. In parting, and to whet your appetites for what could be, I leave you with this: (And yes, I know the orbital physics are all wrong but it is arguably one of the coolest scenes ever, plus B9 has a rear loading ramp like in the film)

I discovered that if you take the Throttle Steering mod and install it in gamedata, then mod the B9 VTOL engines, it works! Four point VTOL with the bac9 engines suddenly becomes vaguely controllable, even without RCS thrusters! However, there is one slight snag if you want to use the rotation feature - the prograde / retrograde indicators do not follow the angle of the engines. Ideally, if coming in to land, you would want to land sort of like a rocket - line up the heading indicator (-w- symbol) with retrograde, burn and keep the w in the retrograde symbol. However, once you rotate the engines down, that all goes out the window. So some sort of code in the DLL to insert icon(s) onto the navball depending on the angle of these engines would be really handy. Failing that, if anyone knows the code to insert the symbol on the navball, I can compile a dll to do it maybe. I had a bit of a dig around but I cant quite work out how to do it - any help appreciated.

Sweet, thank you!

Well, I have modulemanager.dll compiling, but I cannot get any of the print statements to output anything, so I cannot debug

All I know is that the B9 SABRE engines break ModuleManager. If you remove the folders Engine_SABRE_M and Engine_SABRE_S from B9, this mod works again. I will have a look at the MM source and see if I can find a fix, however I am new to C# coding and there is no sln file, so building a new DLL may be a problem for me.

LOL, try this recipe for a little WTF??: Go into VAB, start with drone core, add a jumbo64 fuel tank (36 tons of weight - this is our "payload") 8x symmetry, add 8 RNM intakes to the jumbo64. Repeat - stack the 2nd set of RNMs on top of the 1st set Add 8x stock mk1 jet fuel fuselages Add 8x turbojets = 36 tons VTOL to 75k apo on about 1 ton of jet fuel Who needs first stage rockets?

It seems though that the RNM intake is utterly ridiculous. I used to have 4 ram intakes on my SSTO for every engine - now with 1 RNM intake per engine, whereas I had to work for a 72k orbit, I now have trouble keeping my apo to below 250k, even on a 5deg ascent - the thing rockets out the atmo like a bat out of hell. Whereas before I could lift 40 tons, now it is more like 75 or 100. See for yourself.

Mk2 Released Now lifts 75+ tons 119 part reduction B9 R3 intakes Nosecones Info dialog Bays start closed

Bug report: If you have "Auto stage" enabled in "Ascent Guidance", if you then say switch to a spaceplane and use SMART ASS SURF mode, it auto-stages. In fact, every time I launch my spaceplane, Auto-Stage is ticked again, and I have to untick it

Oh and could we have the H50 legs use the new anim system, so we can start them deployed?

http://forum.kerbalspaceprogram.com/showthread.php/25241-0-20-2-B9-Aerospace-Pack-R3-New-pods-IVAs-engines-fuselages-structures?p=426254&viewfull=1#post426254 Kind of on hold until we have a solution to that. You could quite easily mod ESP yourself for the new wide body bay if you do not need the tail load ramp though. Regarding the docking port at the front of the bay: This is NOT attached to the node (That is where the bay attaches), it is surface attached. If you have Edtools, enable vsnap - else place it anywhere on the face, save the craft and edit the file to make the x and y coords of the docking port the same as the cockpit.

Any chance we could get a hollow version of the "S2 Fuselage Wide Body 3.75m Adapter"? The new wide body bay is awesome, but you cannot use the ramp load tail with it properly - this would solve that.

Heh, the new B9 just launched with a bigger bay and a bunch of other tweaks too. Stay tuned for a Mk2 of ESP

What bay is that?