imasquare

@tseitsei89 Nice job. Looks like I'm going to have to add more rockets to my design...then add some more...and even more again.

Four man 70km @ 44.7s landing @ 24:12 Three man 70km @ 43.54s landing 28:14 I'll post the video for the three man time tomorrow. I've got to do some downloading overnight.

Going to be uploading a fastest for 2,3 crew (They're the same record aren't they?) before too long to reach 70km @ 43.54 seconds. Splash down is 27 or 28 minutes so no record there. Upload times are a pain...

With great difficulty I beat Cunjo Carl's time but not by very much Record for fastest time to space for one kerbal of 40.78 seconds. Splashdown 28:14 https://youtu.be/NrOPZLS4_dQ Because this time was so close to Cunjo's I ran a little kOS script to print out the mission time when 70km has been reached. CLEARSCREEN. WAIT UNTIL SHIP:STATUS = "FLYING". PRINT "LAUNCHED". WAIT UNTIL SHIP:ALTITUDE >=70000. PRINT "MISSION TIME @ 70,000M:". PRINT MISSIONTIME. Ok it should be uploaded now Wait how do you embed a video?

It seems like it is trying to render with the scatterer on Duna but instead I get a bunch of hexagonish artifacts that seem to be the Duna scatter. It works perfectly on Kerbin, haven't been to any other planets like Eve yet.

If it hasn't already been suggested in the past 100 pages. Mission parameter: Mass of the final vehicle achieving the objective or stage. Also the greater the mass of the final vehicle achieving, the greater the reward. Getting the reward to scale up could be interesting, as the greater the mass, the exponentially greater amount of fuel required.

Fractal, do you mind if I release bigger part.cfg files to provide 2.5m and 3.75m parts for people who don't know how to edit these files?

Hi Fractal, I'm looking for the part.cfg to modify for the B9 Aero style scoop, I want to make a 3.75m version of it to mate it to a 3.75m version of the thermal turbojet which...looks awesome when there are 5 of them ploughing you through the atmosphere at 800m/s. I find I had to scale up the fusion reactors as well. My reasoning is less to do with cheating and more to do with reducing part count so things are less floppy and explodey. It's been tricky doing all the spread sheets and keeping the scaling the same or similar energy levels. It would be nice if you scaled up all parts to 3.75m, or better yet 5m for when packing it with 5m nova punch parts. I don't really care if the graphics look a bit stretched, it would save me time and part count in having to do it myself and check everything every release...and knowing it's correctly within your scaling as well. Edit: Nevermind, it wasn't B9 it was warpAtmIntake. Still it would be nice to see all sizes up to 5m as stock delivery.

Hm, I somewhat like the idea of gates et el. Does anyone remember the gates from Mass Effect? How they had to travel next to them at speed for them to be slingshotted off another system. I was thinking something similar could be implemented, you fly at the 'McGuffin Gate/Object', and depending on your initial velocity/angle - you will then be sling-shotted off into a distance that may be logarithmically/square etc. proportional to these values. If you use the right values you can be thrown to a different star system near the target planet, if you're off a bit you may be on the outside, if you're off by a margin more you wind up lost...in space. The above solution would require skill in setting the correct apoapsis and burn times for the encounter with the 'McGuffin Gate/Object', it could be fun and rewarding, yet comical if you get it wrong. You're able to find these other star systems with 'McGuffin Gate/Objects' using the telescopes/radio telescopes you research on Kerbin, and they show up on a larger map of the galaxy/cluster etc. I think this may be able to keep the spirit of building simple rocket ships, but also expanding the KSP universe and keeping it fun. Although warp drives are a good idea, they don't seem to be in the spirit of what KSP is trying to achieve. Having said all of the above, as mentioned previously I would rather see FTL/other systems implemented in DLC.

That's the crux of it, well said. It seems that some people want super realistic simulations right down to the scale of atom interactions requiring a football stadium sized super-compute-cluster, whilst others just want...an approximate emulation that their humble PC can play. I'm not sure what Squad wants to deliver.

The short answer is, there is nothing wrong with your monitor, graphics card, game, installation or configuration. Rkman and The Right Trousers are correct. However this is a completely normal effect of having a large and wide FOV. It only seems strange as you have human eyes, and you're used to perceiving the world with a narrower FOV.

I agree that assistance with assessing the stress and strain during build and flight would improve gameplay experience, I had similar thoughts on this aspect of gameplay myself. After Squad has fixed the buggy physics emulation to the best of their abilities, I'd suggest Squad review this item. My thought is if the physics emulation is fixed to the point where ships don't wobble around so damn much we hopefully won't need this function so soon. I'm not saying this feature isn't needed, but there is a game play pain point revolving around the wibbly wobbly ships that tear themselves apart for no realistic or reasonable reason - that should be resolved first,

Everything may seem 'relatively trivial' even with known procedural generation techniques for planets. However it has has nothing to do with project management and the current list of deliverables listed by Squad. If the deliverables are finalised before schedule and the project is under budget - then Squad can look at this task and see if it's feasible with the remaining time and budget for KSP 1.0.x GA release. I'd look at scheduling this as a separate project that is a paid for DLC pack, development would be after KSP 1.0.x GA release.

There are some interesting discussions on physics, theoretical and otherwise. Would going to other star systems be interesting? Of course. If you want that I'd suggest you go and play Spore, it has some good 'space age' flight between star systems. Flight to other systems may be a possibility for a sequel, otherwise I don't see this project scope addition being practically achieved within the current time and fiscal constraints of Squad.

Some good suggestions to update the the art/model assets, I'd suggest the Squad team look at this after some of the major developmental pieces are completed and are near the 1.0.x GA release.

Really? Hm, well I guess it isn't too difficult to implement a procedurally generated galaxy/universe like in 'Spore', however at this moment the KSP 1.0.x GA release should not include FTL/Trekkie-Transwarp-Drive-Thing within the scope of deliverables to go to these locations. IF, and only IF they decide to do a sequel to KSP where they adventure beyond the local solar system, THEN maybe I would consider it. Squad has a limited time and capital to achieve their planned goals, the team needs to focus their efforts on the current list of planned features, and optimising and fixing their existing gameplay issues.

I concur, an anti-matter type 'engine' is too sci-fi for the KSP universe at the moment, in addition the physics engine would be likely unable to handle the engine power properly and destroy your ship in the process. For the moment this should be out of scope of stock KSP deliverables.

I agree with the principle of what this suggestion is trying to achieve, and that the Procedural Fairings mod needs to be made stock. There is a great debate over the physics and wobbling of the game, and the inherent issues with the physics engine and realism etc. etc. and I side on that of simplifying things for balance and stability of medium and large payloads. After many frustrating failed launches of large or complex loads, I pondered briefly on how real life rockets can be much larger, deliver delicate, intricate and expensive payloads without anywhere near as much issues. Basically we're given lego blocks to try to put together a high powered launch vehicle, simulated using single points of physics between parts on a single cpu core - and it just doesn't work properly without putting struts all over it like piano wire spider webs and even then it just isn't fun any more. I would rather treat the object(s) inside the fairing with simplified physics, because it's not enjoyable to try and do all sorts of re-enforcements with the given tools in KSP. I can't re-create a useable version of the 2800 ton Saturn V rocket in KSP because I am constrained by the 'KSP Laws of PhysX' which are terrible - not the laws of real physics. Frankly I would rather see rigid whole body physics for each whole ship in KSP until such time that the ship actually impacts with the ground, another craft or a celestial body. I understand people can see this as rewarding 'bad rocket/aircraft design'. Again, bad design using simplistic Lego pieces? ...actually you know what? I think lego rocket/aircraft would be more stable because you'd have at least 4 to 8 points of interconnect between components for PhysX to calculate. If a load is too complex or delicate, placing it inside the fairing should be like saying 'too complex/impossible to make launchable with KSP tools'. KSP is an arcadish simulator with a simplistic physics engine only capable of supporting relatively simple space craft without strutting it all over the place - but customers yearn for large, complex and sometimes absurdly powerful rockets. Enough of the physics point of view. Let's look at it from a commercial/consumer point of view - because that's what matters most. I am a customer, I have purchased this game, I enjoy this game - but I want to launch bigger and better rockets and payloads because I enjoy doing so. I want big, complex and intricate spacecraft with plenty of lights and moving parts, why? It's fun! But I can not enjoy the game that way because the PhysX engine is not fit for this purpose. On top of enjoying large and intricate spacecraft, I want reasonable frame rates; to help achieve higher frame rates the developers could load in the model for the payload inside the fairing gradually through the ascent or just before fairing jettison or in whatever what is deemed optimal. I have to admit if this game were developed by a larger software house or overseen by a large brand name publisher they would probably put a restriction on both spacecraft mass and number of parts to prevent performance and gameplay experience issues. Then again if they had it were being developed by a larger software house they'd probably look at multithreaded physics engine/GPU acceleration, or maybe clever ways to simplify the physics calculations simulated but still keep the simulated physics satisfactory. So by implementing the ideas suggested by Physcix there is a good chance of increasing performance and gameplay experience of the customer. Better performance and gameplay experience should hopefully lead to more gamers recommending it, and hopefully a flow on in commercial return on sales.