Jump to content

neistridlar

Members
  • Posts

    771
  • Joined

  • Last visited

Everything posted by neistridlar

  1. 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.
  2. 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.
  3. I know about it, and it is my go to tank for this, but I rarely fill it more than half full
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Feel free to use any of my models, and good luck!
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. Maybe you should post a picture of the parts in question, demonstrating the issue.
  20. 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.
  21. I agree with all of the above. I would definitely advise going for more of a self judging system if possible, like most other challenges. I wonder if the challenge would work with a similar format to the K-prize. So have different tiers of achievements, that could easily be determined just from screenshots. At least that would put minimal workload on the judging side of things.
  22. I found it suite easy after I found how to make the most out of the aero in the game. There are a few little things that are easy to do. Make sure that the main wing is at a 2-3 degree angle of incidence. Then make the wings such a size that the fuselage is as close to level as you can, preferably within 0.2 degrees. Also make sure you have nose-/tail-cone of some sort. And make sure you use nodes as much as possible to attach things. And make the plane long and thin, rather than wide and stubby. There is a window you can access under physics/aero. Check the two first boxes. AeroGUI tells you a lot of different things, but the most important are the mach number. Avoid the range from 0.8-1.6, you will find that you burn much more fuel in that regime. The AoA readout is also very useful. Make sure the plane flies as close to 0deg AoA as possible during cruise. Last one to take note of is the L/D. Don't put too much emphasis on this number, but you can use it to compare different variations on the same design. Also you can right click parts and see how much drag each part is producing, which can be helpful in choosing which parts to use. Lastly, don't bring more engine power than you need. Excess engines create excess mass and drag. I probably forgot lots of things, but those should get you going. I do have a few of mine on kerbalX which you can study if you like. Not all of them are good, but they all work.
  23. I think the more realistic version would be, you sell the science. Then spend the money to research new stuff. As for the science collection side of things, I would like to see a system where you can not max out the science for a biome. Say for instance there would be a 500m radius around where the science was taken would be marked as used after 1 sample. That should give more purpose to rovers, while avoiding extreme tedium.
  24. What if the small SOIs in this example were big enough that they actually encapsulate the barycenter. That would avoid the naked singularity issue, and replace it with the low gravity at the SOI edge.
×
×
  • Create New...