vidboi
-
Posts
96 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by vidboi
-
-
The unity game engine is single threaded, and therefore KSP can only use one core of a processor. Your CPU will show that 30% of it's total capacity is being used, but that won't be split evenly between the cores, one of them will be at 100% usage with the others idling. (I'm guessing you have a 4-core or equivalent processor)
-
It's a problem with KSP, not the B9 pack. The navball points in the direction of the part you're controlling from, but looking from the centre of the craft, not the part. An offcentre docking port will as a result not line up correctly when trying to dock using the navball - you've got to do it by eye
-
KSP fuels are around 5times more dense.
Kerbin atmosphere was 35km high at first (up to around 0.8.4).
KSP doesn't actually provide any units for fuel volumes, so no direct comparison can be made. It can be assumed that each unit of fuel is actually 5 litres (which actually fills the volume of the tank quite nicely) and makes liquid fuel and oxidiser roughly comparable to RP-1 and LOx in terms of their properties, which makes more sense.
Kerbin's atmosphere was all the same pressure when it extended to 35km. It was essentially a thick shell of air that made it more efficient to go straight up until you left the atmosphere, and then burn parallel to the ground to get into orbit.
Nice shuttle by the way, it's quite an achievement to get one working nicely!
-
Radial decouplers (the biggest problem).
I tested it, and so they do. I've never noticed that before either.
-
Struts kill the decouplers' ejection force.
This only happens with stack separators. Normal decouplers work fine, but stack separators won't move at all if the two stages are strutted together.
-
Pressing Space will reset the part rotation. (In VAB and SPH, I suspect.)
It also resets the view rotation when you're not holding a part (only found that one out today)
-
Thanks all... following-up...
This would imply that you should always use the engine with the highest ISP for your environment (atmosphere or vacuum), therefore, that the 5xT45s are always the way to go out of the 3 I listed above. But, as you imply later in your post, TWR is a significant factor. The Skipper and the 5xT45s just don't have the thrust to lift the heavy loads, which I think is why so many people use MainSails, which are horribly inefficient. Then does it become a space and weight constraint? You can't fit 7.5 T45s onto the bottom of an orange tank so you can't get to the thrust of a MainSail with the efficiency of a T45.
Mainsails have the best thrust-weight ratio out of all the engines, so for lower delta-v stages using a mainsail can actually be more efficient. Given that it is often more efficient to stage quickly rather than have high delta-v stages (especially in asparagus set-ups) using mainsails can actually be more efficient as the engine contributes less to the overall mass of the stage. Very efficient launchers such as the Nova use mainsails for the asparagus boosters and T30s/T45s for the central stack to make the most out of this behaviour. Another good example is how below a certain delta-v requirement (I think it's around 800m/s) 24-77s are more efficient than LV-Ns.
-
There's no "ASAS" now, it's just the SAS module.
Basically, what used to be the old small ASAS module is just the SAS flight assistance module with a reaction wheel, while the old SAS is now just a reaction wheel.
EDIT: Since there seem to be a lot of confusion, here's a link to help you guys understand better.
Basically, the SAS module does the job of the old ASAS module, it uses gimbals, RCS, control surface and pod torque to steer your ship. The control wheels just provide more torque.
Actually that's not quite correct, ASAS does still exist (albeit in an updated form) it's just called SAS now and is included by default in all command pods and probes. What was called SAS (which only served to slow rotation before itself, not keep a heading using all available control features like the old ASAS and the new SAS) no longer exists, and the model has been repurposed as additional reaction wheels to provide extra control over your craft. Given that all craft with a pod have ASAS/SAS features already built in, the SAS module is unnecessary for it's extra weight.
-
Okay, the big question is, is Mechjeb capable of automatically landing a craft like that, even when it has no probe body (maybe only possible since 0.21)? Because if the engine ignited, it seems very much like an automated powered descend...
The Mechjeb part is a probe body itself capable of controlling the craft. I believe it does continue to act on the craft after switching and whilst remaining in loading range, which would explain the behaviour here.
-
Any status on fixing the struts and fuel lines problems?
Saving a subassembly by dragging it directly off of the rocket/plane (NOT using alt-click to copy it) works every time for me and keeps all struts and fuel lines intact.
I believe that the problem happens when parts are copied off the rocket to make a subassembly, as the struts and fuel lines are only connected after the copied part is placed on the rocket/plane and therefore aren't connected in the saved subassembly. If this is the case, it isn't something that the mod can fix.
-
Lets put it this way,
Every part has a size, shape, mass, and performance to be considered.
Clipping ignores size and shape and only adds mass and performance.
That relegates your craft to have magic properties that a standard craft would not. No different than turning on infinite fuel.
But KSP's physics doesn't take size and shape into account, so it's exactly the same gameplay wise as a non-clipped craft. It's completely different to turning on infinite fuel...
-
I don't know why I keep seeing threads asking about efficiency when from many pics i see it seems that efficiency is least concern. If you want efficient, think LT-Ns, lots of tanks and little else except staging.
That's not efficiency, that's just your amount delta-v. Your efficiency is how much delta-v you use for a given manoeuvre, which is what this concerns. Given that gimballing engines help your rockets staying pointing in the right direction (i.e. towards the prograde direction) I'm sure the losses are more than made up for, and the new 0.21 ASAS should eliminate gimbal oscillations.
-
Isn't there even a tutorial on this? In game?
There's the whole "Training" section under "Start game". The second one teaches you how to launch and fly a rocket. If anything the tutorials in KSP now are more comprehensive than most finished games...
-
Seems like installing a launch escape system paid off...
-
If I might add my two cents?...
100% stock
Heck, there's a whole challenge thread: http://forum.kerbalspaceprogram.com/showthread.php/39630-Doing-it-Apollo-style although I don't think anyone can quite match Mulbin's attention to detail with Munbug IX, that thing is a beauty!
-
Here we go, not quite as aesthetically accurate and pleasing as Mulbin's Munbug, but I had a lot of fun building and flying an Apollo-Saturn V like rocket.
The rest of the gallery can be found here: http://www.majhost.com/cgi-bin/gallery.cgi?f=278554
The mission should fulfill all the objectives in the first post:
- 3-man Mission +10
- 2-man Lander +10
- 2-stage Lander (leave the decent-engine on the mün) +20
- Escape tower? +10
- Lander stored behind the CM during ascent +20
- Lander tucked away behind some fairing? +5 (the fairing style is different to the actual Apollo style, but I guess it still counts?)
- Free return trajectory to the mün +10
- Flawless landing (no parts broke off, Neil Armstrong is watching you!) +10
- Got a Munar Roving Vehicle (MRV) on board? +15
- After succesfull Mün landing docked CM and MM in Orbit (no swapping ships without docking them first) +10
- MM disposed by crashing it into the Mün (remove Kerbal first!) +5
- Plant flag on the Mün (no cumulative, i.e. two flags don't get you 6 points) +3
- Spashing down on Kerbin (land on water) +5
For a total of 163 points!
For good measure, I also put a small satellite into low munar orbit, just like in the real missions (hopefully it hasn't crashed yet...)
-
After spending some time planning and re-planning an extended Duna mission, I've settled on a plan that I'm happy with, and plan to carry it out over the next week or so.
The mission will land 6 Kerbals on Duna around day 350, giving an early mission score of atleast 750, followed by a further 6 shortly after day 800 increasing the extended mission score to almost 5000. Although not as high as some of the Kermmunist proposals, the mission is designed to thorough and robust and plant the foundations of a Duna colony that can be extended well past the initial mission plan.
In terms of achievements, the plan is designed to achieve a maximum of 12 achievement points if everything goes well. All base modules will be self-mobile and capable of operating independently, and smaller exploration rovers will be delivered during phase 4, ensuring all Duna crew have maximum mobility. The mission vehicles are designed with multiple redundant life support systems and backups, with the Duna transports capable of performing both Kerbin-Duna and Duna-Kerbin transfers on their own with delta-v to spare as well as being emergency Duna landers, and other mission vehicles (Duna lander, light Duna tug) are capable of replacing their propulsion systems in the event of failure. Kerbin-Duna transfers will be done in two parts with the use of nuclear powered boost tugs, and an unsuccessful insertion burn should be safely recovered from. A refuelling station will be placed in Duna orbit in phase 1 with enough fuel alone to refuel the lander and provide enough fuel for both of the Duna transports to return to Kerbin even if completely empty, and this will augmented in further missions with additional fuel and Kethane refining facilities.
Launches are split into 3 categories: minor (green), major (yellow) and critical (red). Loss of a vehicle during launch or Kerbin orbit operations will result in a replacement launch taking the place of a less important launch (i.e. a minor vehicle) in order to successfully complete the phase of the mission, and all phases have minor launches to ensure this is possible. Loss of non-critical vehicles at Duna will not seriously affect the mission, with major vehicles being replaced as soon as possible (hopefully within the next launch vehicle). Loss of a critical vehicle however may put the entire mission in jeopardy, and therefore will result in a replacement being launched at the next possible launch opportunity and then being propelled to Duna on a non-optimal trajectory by the Duna boost tug 1 that will remain in Kerbin orbit in case of such a situation.
Overall, the mission is planned to be both safe and productive, with a very low chance of overall failure.
Onto the vehicles themselves:
Launches will be performed by the as yet unchristened single use, 3.5 stage, 15 ton launcher AL015t:
Although it's far from the efficient launch vehicle I wanted something that could fairly reliably heft payload into a 100km orbit and be fairly interesting at the same time (hence the over the top staging).
Phase 1 comprises of two parts: the first being a light nuclear tug with mapping satellites and a rover-skycrane combo used to decide on an optimal landing site for the main base:
and the second part being a refuelling station for Duna orbit:
These two launches will be docked together and travel to Duna as one.
Phase 2 starts with the launch of a fuel station of the same design of that launched in phase 1. This will provide refueling facilities for vehicles in Kerbin orbit and a place to collect and assemble the stacks of modules to be transferred together.
The next launch is the Duna boost tug used to put the two stacks of modules into a highly elliptical near-escape orbit around Kerbin. The tug will aerobrake back into Kerbin orbit using the shields around it's engines and refuel at the station for the next transfer.
The two Duna transports are launched unmanned and use their own power to circularise. They will each carry three Kerbals to Duna, and their engines are used to perform the second transfer burn to put them into a Duna transfer orbit after the initial boost. They carry all the hab space and life support needed for transfers between Kerbin and Duna and vice versa.
The Duna Lander is used solely to transport Kerbals between Duna orbit and Duna surface. It is initially planned to make two trips (refuelling at the supply station launched in phase 1) and will remain on the surface of duna for rapid evacuation in emergency. The remaining crew will be rescued either by a second trip or an emergency landing by a Duna transport, depending upon the urgency of the situation.
The Duna station provides addition fuel, habitation and life support systems to remain in orbit around Duna. This can effectively support all the Kerbals on the mission at any time in case of emergency with habitation space in the transports, but will mainly just provide more fuel and short term hab space.
Last but far from least are the Duna surface modules. These will land, unmanned, separately and then join together before the crew take the lander down to their new home for the coming years. The modules are designed to be fully functional independently with individual life support facilities, with extended capabilities when joined together. Modules are landed via parachutes and single use retro rockets.
The vehicle used to transfer crew to and from Kerbin orbit is the Atmos L orbiter launched on top of a cost-effective 2 stage launcher. The crew will be launched in the days shortly before the transfer window in order to prevent depletion of supplies and limit stress to the spacecraft systems, with prior testing done remotely.
Phase 3 and 4 vehicle designs have yet to be finalised, however many of them will be the same or very similar to the phase 2 vehicles.
Mods to be used:
-Mechjeb 2
-KW Rocketry
-B9 Aerospace (structural parts)
-Crew Manifest
-Kethane
-Ioncross Crew Support
-ISA Mapsat
Now it's just time to finish testing and start the actual mission...
-
It doesn't actually matter whether the centre of thrust is in front of or behind the centre of mass, this is known as the "rocket fallacy". As long as the thrust vectro is aligned so that it points through the centre of mass you're fine. What does matter is the positioning of the centre of life. This needs to be behind the centre of mass for the plane to be stable, however too far behind and you'll have difficulty controllign the plane and it may have a tendency to nose down. Essentially you want your centre of life to be just behind your centre of mass, and your thrust vector to point through your centre of mass.
-
Asparagus staging is great when it works, and sometimes also when it fails. Lots of pretty rocket trails to watch!
I'll second that!
-
Hey guys. First of all - Bac9 and all devs of this great mod - thank you, bow down. I myself used to make models for other games such as Homeworld by starting from things I myself wanted to see.
Now, I have a few questions, I hope someone can answer:
1. How do you hide your struts? I am unable to place them in between parts(say 2 fuel tanks mounted next to each other)? This is in case i still need struts, after instaling 2.4( running 2.3 now, no FAR).
2. Can someone recommend a mod, including some larger landing gear, I am having trouble taking off with the ridiculously small stock ones?
3. How do you place docking ports in the HL and M2(i think) cargo bays? I manage placing them, but off-center, even if it's 1 pixel, they just won't attach to the center node, they just rotate around it. I have tried attaching docking ports first, but then you can't attach the cargo bay itself.
1. I find turning off angle snap helps to place struts between adjacent parts. I just make mine a short as possible in out of view places to try and hide them as best as possible, however the only parts I've really felt the need to strut are the HL cargo bays and tail section (and possibly the side extensions if they get very long).
2. My suggestions would either be Taverius' pack or TouhouTorpedo's modular multiwheels, which I use myself (see the screenshot below for an example)
3. Once again, turn off angle snap and the docking port will lie flush with the surface, allowing you to place it approximately in the middle.
But yeah, thanks to Bac9 and Taverius for this great section pack! I've had a lot of fun already even if there are still a few more bugs to be ironed out.
Impact resistance does seem a bit high however, and doesn't seem to help planes staying together in the air, but does stop anything from being damaged by the ground. The cargo bays and HL tail sections seem particularly weak, even with strutting, and tend to fall apart when pitching up or down too hard (such as taking off or landing...). It'd be nice to have a cargo bay section without opening doors for loading cargo into and still allowing top mounted wings, and possibly an opening nose section to load cargo as well.
System requirements of .21 to .18
in Welcome Aboard
Posted
v0.21 requires a lot more memory than the demo, in fact it even requires a considerable amount more memory than v0.20. A stock install now uses 1.4GB of memory just to launch the game making the minimum requirement 4GB RAM or more, and makes it almost unplayable on 32-bit systems due to the 2GB memory limit, as 2GB isn't enough even to play the game stock without periodic crashes. If you're experiencing a significant slowdown from the demo to the full game, it's likely that you don't have enough memory.