neistridlar

I think the way to deal with this in KSP2 would be to give players to enable "override mode", which would essentially revert to KSP1 style maneuver nodes. Should be plenty good for most purposes, without the game having to know the thrust and mass of your ship.

I think the way to deal with this in KSP2 would be to give players to enable "override mode", which would essentially revert to KSP1 style maneuver nodes. Should be plenty good for most purposes, without the game having to know the thrust and mass of your ship. Wrong thread All burns were inaccurate to some extent, but the longer the burn, the worse the accuracy, because KSP1 assumes the burn takes 0 seconds. It's mostly noticeable when burns start to last a significant portion of the orbital period. So for low Kerbin orbit for instance, a 1 minute burn, it's not really noticable, but a 5 minute burn it starts to become significant.

Was going to suggest this my self. I hope we can get a completely manual version, with the current trips only being templates, so you can quick fill the trip plan, then customize to your hearts content. Say for instance you want to do a jool 5 trip? Or maybe you want to go to the mun, land, reorbit, land in a different spot, then return to kerbin? I think it would be nice if there was a pluss icon at the bottom of the list, click it, and pick from a list of relevant "destinations" and the game automatically fills in the necessary dVs.

From what I figured out, there is some black magic going on with the coordinate systems. If every coordinate system is lined up the right way it works as expected. As for Neist Air I started off on the wrong foot so to speak, and figured out a workaround, which I can't quite remember any more, but I think I put the IVA props in an empty that was turned 180 degrees to correct my error or something like that.

@kerbmario Is now making updates for Neist Airliner Parts: https://spacedock.info/mod/3034/NeistAir%20Reupdated

This looks really promising. Definitely leaps and bounds ahead of KSP1! Like @mcwaffles2003, I too was wondering about underexpanded plumes. It seems only the overexpanded side is represented here. Granted underexpanded engines are very limited in real life use, due to flow separation, this issue is handled differently, at least in KSP1. If nothing else I think an underexpanded plumes would be a nice cue to the player that they are using a suboptimal engine for the current conditions. An other minor issue: In the video demonstration, the speed of the low throttle exhaust seems ridiculously slow. I may very well be wrong, but it is my understanding that exhaust flow speed for chemical rockets should always be supersonic, and that exhaust speed is directly linked to specific impulse of the engine. In other words, the exhaust speed should always be pretty darn fast.

You must not be familiar with the conventions for version numbers. It is not a regular decimal number, the period is simply a deliminator to separate major and minor versions. So 1.2 came out a long time ago. And 1.9 came before 1.10. 1.99 will come before 1.100 etc.

I know about it, and it is my go to tank for this, but I rarely fill it more than half full

I'll have to disagree. I've played a bunch with restock, which has equivalent sized RCS thrusters. I found myself using them as main thrusters for tiny comsats, where tiny thrust is a desirable feature for accurate orbital insertions. I also found them more than adequate for smaller 2.5m craft as well. Sure I could have docked them without RCS, but it,s so much more convenient, and realistic for that matter with RCS. It's also convenient for fine orbital adjustments. The light weight and low thrust make them very suitable for such applications, not to mention more realistic than for instance very short low thrust burns with the main engines. Needless to say I welcome this addition to the base game. That said, there certainly is a place in this game for more vernor-sized or bigger thrusters for RCS use as well. I hope they also ad some smaller RCS tanks suitable for very small comsats as well. I find my comsats often only need a couple hundred m/s DeltaV after detaching from the "mothership" in order to spread out into their respective orbits. I'll have to disagree. I've played a bunch with restock, which has equivalent sized RCS thrusters. I found myself using them as main thrusters for tiny comsats, where tiny thrust is a desirable feature for accurate orbital insertions. I also found them more than adequate for smaller 2.5m craft as well. Sure I could have docked them without RCS, but it,s so much more convenient, and realistic for that matter with RCS. It's also convenient for fine orbital adjustments. The light weight and low thrust make them very suitable for such applications, not to mention more realistic than for instance very short low thrust burns with the main engines. Needless to say I welcome this addition to the base game. That said, there certainly is a place in this game for more vernor-sized or bigger thrusters for RCS use as well. I hope they also ad some smaller RCS tanks suitable for very small comsats as well. I find my comsats often only need a couple hundred m/s DeltaV after detaching from the "mothership" in order to spread out into their respective orbits.

Thanks to @Commodore_32 for reporting bugged TCS nodes. It turned out they were simply backwards. New release is now available on Github. Also thanks to @Lisias which cleaned up the configs and bulkheads a bit.

If someone want to put it on CKAN and manage it without my involvement, I'm not oposed to that*. But I'm not interested in investing any of my own time to make it happen. *in fact I don't think I can deny any one making a "CKAN edition" of NAP, and posting puting it on CKAN, given the licensing I'm using.

Interesting. I have yet to try out 1.10. Just to rule things out, have you tried it on a clean install? Has anyone else seen this issue (or not seen it)? I can't promise I will look at it soon, but I will probably get around to it eventually.

Feel free to use any of my models, and good luck!

I use primarily Blender for the modeling (Though I also use Fusion 360 to create reference models for some parts). For the texturing I use Incscape to lay out the panel lines and other "mechanical" details, like windows. Then I export it to GIMP where I apply weathering and more "organic" details.

I'm unsure what exactly you mean, but it should work just fine both on it's own, and side by side with APP. I will take that into account.

So, I've been meaning to do this for about a year now: https://github.com/neistridlar/Neist-Airliner-Parts/releases For those that have cloned the repository within the last year there should be nothing new here I think. However for those that find that sentence intimidating, there is now an easier way to get the latest and greatest. I think this is what is "new": B73 cockpit added 12NCS-B73 added CS22 cockpit added 12NCS-CS22 added A38 cockpit added 18NCS-A38 added 50PC added 37-50AD Added Adapters now have proper textures Some IVAs have been populated with props. Possibly other stuff that I don't remember.

I'm unable to work on it for now, due to mental health issues. I'm still thinking about it now and then though. I did consider these options when I designed the parts, however the current solution was the best I could come up with, while still maintaining the stock "lego" feel to my liking. I do have plans for a few more engines. CFM56 is certainly a candidate for 1.25m, though APP has one, so I have been looking for other candidates. Also have some plans for this, two nose cones, one with passengers and one with "shark mouth" opening for cargo, and cockpit, structural, passenger and end piece for the hump. Made to fit primarily 3.75m, because it is the closest, but hopefully won't look too bad with 5m either. For now though, I advise everyone keep expectations low and patience high.

I've longed for this feature many a times for my spaceplanes. I rarely find myself with the perfect oxidizer/liquid fuel balance once in rocket mode. Being able to dump the excess would increase the available Delta-V. Dumping the remaining propellants can make reentry easier as well.

With regards to classes, I think the original classes (pre hoppers) is mostly fine. Those that bother me the most are jumbo and sea plane, and to some extent supersonic. The issue I have is the openness. With enormous variations in speed, size and range, it is very difficult to compare and judge. For supersonic I'd put a roof on passenger capacity of say 64. Prohibit supersonic jumbos (and any other category). Also limit seaplane to say 40 seats. As for sub categories, I don't particularly like it. I think it's good enough as has been done previously, with judges giving a comment on what that particular plane might be useful for.

I do like this Idea. Maybe er vold divide the ckasses into tiers. Say turboprop/small regional is tier 1, medium regional and dra plane tier 2, and jumbo and supersonic tier 3. You would have to have at least one plane "approved" before they could move on to the next tier. Agreed. Only thing is I'm not sure the mk1 needs the price increase as well. IIRC it wil end up as the heaviest pr. Seat, which means the kppms will suffer, especially for long range aircrafts, as the fuel/mass fraction gets quite high on those. Might need to build a few "benchmark"-aircraft by those rules, just to test it out.

Yup, we definitively need something like this. Though believe it or not the current queue would only loose 1 or 2 planes with a 6 plane limit (just from looking over it quickly). Though there have certainly been points in time where it would have cut down the queue more. By my count there is ~50 unique contestants in the queue currently, with ~110 submissions between them. I feel like a limit of 3 might be necessary to keep things manageable. This does sound intriguing. However, I do fear that it will be too complicated for a lot of forum users to comply with the rules, judging by how many miss things with the current rule set.

The thrust for all airbreathing engines depends on the mach number. There is a curve in the config that defines the relationship. In general APP engines have very high thurst at low speed, taper off as speed increases, then drop off sharply when the engine reaches its intended top speed. The thrust falloff is to simulate thrust lapse, that is as you increase your speed through the air, the jet exhaust/propwash has less of a speed difference compared to the surrounding air. This causes reduced thrust and efficiency IRL. Some has a little lower static thrust to simulate stalled out props, or spool up time for turbines I think.

The ReStock guys are very skilled artist putting in a lot of hours every day to make it happen, sure they do it for free, but it is still an enormous amount of work. The guys at Squad are making their living from this, so time is money. So they really need to consider how much time to put in vs. how much that time is going to pay in form of new sales. The ReStock guys already got their bills payed from their jobs, so they don't necessarily have that consideration. This long into the games lifespan I'm quite frankly amazed that Squad is still finding it worthwhile to continue development. Anyhow, I think the revamped cargo-bays are a good improvement over the old ones.

Maybe you should post a picture of the parts in question, demonstrating the issue.

1) Except, KSP1 reduces the forces on each face that is node-attached to another part, 2) Offsetting a part does not change the size of the aerodynamic forces on the part 3) We can rotate nose-cones 180° and avoid the leading-face drag in favor of the much lower trailing-face drag. 4) Except, any part inside a closed container feels zero aerodynamic forces, These would all go away if they ditched the drag cube system, and in stead adopted a voxel based system similar to what FAR uses. The drag cube system is good enough for very simple rockets and planes, but there is so much that does not work in an intuitive and realistic way due to it's limitations. Say for instance you built a cargobay out of wing sections or structural panels, put it in line with your fuselage, and blended it all nicely together. Well, all you are achieving is to create massive amounts of drag, while you would expect such a contraption to create very little drag. Switching over to a voxel based system would make this work as expected, and open up for much more interesting and kerbal designs. 7) Skin drag, from faces of a part parallel to the airflow, use the same shape factor Cd as they would have when facing the airflow. This combined with the way drag cubes are calculated makes parts with flatish sides, such as Mk2 and Mk3, and many other profiles invented by the community a lot more draggy than they should be. The reason being that the Cd for a flat surface facing straight into the air-stream is very high, but a flat surface parallel to the airflow should not create much more drag than an equivalent rounded or slanted surface, both of which gets lower Cd. In fact with the current drag cube system you can get a squareish profile to generate a lot less drag over all if you rotate it on edge, so that it is pointy in stead of flat from the sides, before the drag cube is generated. After that you can rotate it back, so it is essentially identical to one that did not have it's drag cubes generated while sitting flat. That is just stupid as far as I'm concerned. 6) The forces on wings as a function of angle-of-attack give a very soft stall 9) The lift on wings as a function of mach number, is higher at low speed, lower lift at high speed I think these should be kept. It makes aircraft design more forgiving. It is hard enough for most players already, and most of the basic principles of plane design still applies. Also, changing this I think is what will alienate most players. Forcing the full complexity of FAR onto everyone is probably not going to be a good Idea.