DundraL

Haha, a while back I wanted to do something similar with the pixels on a computer screen. With reduced resolution and color count, it is possible to systematically display every single possible combination of pixels on the screen... in a lifetime. Think about it.... Though the would mostly be random garbage on screen at some point there would be a picture of: Earth from space. A cartoon of you eating a tire. A picture of your mother holding a burning ketchup bottle. A blueprint for an undiscovered technology. Consider that text can be part of a picture.... The text of any national anthem, past current or future. Lyric to an unwritten song. A correct (and incorrect) text explaining about how the last human dies. etc.... every picture you can think of... yea you prb get the idea.

Yes it's possible. Just as rockets use chemical energy to fling mass out the back, you can also use magnetic fields to fling charged particles out the back.

Anyway... back on topic.... As usual, I suck with words. Here's what I meant: I like this way because it can handle 30 degree slopes without tipping, and its easy to get in and out on kerbin once landed. It is also like to point the right direction during ascent AND descent. Its stable but not so stable you cant turn it to steer where you need it. Another idea that might work is for some pods to have their CoM adjusted towards their floors. That would help it during descent but hurt it during ascent, though you would have alot of room for stabilizing during ascent. It wouldnt do much overall but it would help with tiny capsule reentry.

Well from what I see, what you have is a design problem: Those fuel tanks act like giant fins when empty. If you kept them full I bet it would fly like you wanted.... but why haul dead weight around? Try a lander can with a heatshield on bottom with the tank above it. Thats what I usually do, as it keeps the CoM high on ascent and low on decent. That and it reduces the need for ladders etc.

Hi, just showing up with an item for the wishlist: a checkbox to calculate with airbrakes deployed. Considering they make a major impact of trajectory, I think being able to include them would be a pretty big change for the better. Anyway, thanks for the awesome mod, cant live without it!

sounds great. add tech tree unlocks to be funds, and you got a hole in one =) TBH, I always thought sandbox players would really enjoy contracts even though they dont get any resources from em.

Wow, I didnt know about the inline fairing bit... still wont let me build the fairing first to allow for easier engine clusters.. but ... thats good enough I guess

I DO do that... but IMO, I think it would be nice to be able disable a probe core on a manned flight till I need it for automated return for example. Or maybe I don't need 5 probe cores draining batteries when I launch a rocket delivering multiple satellites to orbit.

Well, just as the title says this is a list of ideas I don't think merit an entire thread by themselves. If an idea gets alot of interest, or if I cant explain it properly in a paragraph, I may give it its own thread. TLDR: Dont post. 1: Add a fuel pumping function to docking node context menus: A click of a button starts evenly draining fuel from tanks on one side of the docking port and putting them evenly into the fuel tanks on the other side of the docking port. Simply moves fuel from one side of the part tree to the other (relative to the dockingport) . Fuel flow logic would still apply. (no effect on locked tanks or tanks separated with a decoupler.) This is to allow for an easy fill up at orbital depots, without coding to try to keep track of what parts are new to the current part tree. 2: Clicking altimeter to toggle between the display between sea-level and radar altimeter. Pretty self explanatory for the reason. Maybe a little indicator telling you which mode its in. 3:Jet engines: handle intake air indirectly to prevent asymmetric thrust. (its still a thing) by calculating TOTAL intake air rate (from all intakes) and TOTAL intake demand (from all engines) you can use that to apply the resulting performance changes to ALL engines. Directly subtracting intake air from each engine will eventually result in the last engine to take its slice of the pie to get less pie than the rest so to speak. 4:Handle the mass of intakes and jet engines as a system, not as independent components. This will allow more control of an aircraft's CoM. That or reduce weight on jet engines by a fixed amount and add that much weight to intakes. please note this thread has nothing to do with aero, thrust, altitudes etc. http://forum.kerbalspaceprogram.com/threads/92819-An-arguement-for-a-simple-intake-jet-engine-tweak for more into on that problem. 5:Move electrical and thermal parts to their own tab in the editor. The utilities tab is getting over-crowded. Moving solar panels, batteries, fuel cells etc to their own tab. 14 parts I think. Make the tab have a lightning bolt on it. Should be pretty easy to learn. 6:Solar cells: Change the texture to show that it has a radiator on the back. This will help players realize the additional function of solar cells faster. 7:Science parts: Add a new science tab beside the resources tab for the in-flight UI. Clicking it should show you a clickable list of science parts on your vessel. Clicking one should result in "using" that experiment. Unusable ones should be greyed out or list the reason they are unusable/ already used. Should highlight the part like hovering your mouse over the part. Keeps you from having to mess with the camera to get it inside those service bays. 8:Bacon: make it crispy and delicious. Dang now I'm hungry. 9: Probe cores: give them a stand-by or hibernation mode in their right click menu. This makes the vessel uncontrollable, but the core stops using power. You can of course still bring it back out of standby. BONUS: put probe cores in standby when their battery gets really low. Make it a slider in the right click menu labeled "standby at power %" It would give us one last chance to deploy solar panels before a probe is lost. 10:An extra level of time warp available only on solar orbit above 50,000,000M.... Even at current max warp, it takes ages for things to happen way out there. 11:An easy way to do inline fairings based on squads UI. (assuming you are in the process of making a fairing already) click the rim of the fairing you are making (or press space?) to leave the top of the fairing open and create TWO (2) attachment nodes at the height of the farthest fairing section. yay, now we can have engine clusters for mid-stages.;Fail, this is already almost done and I didnt know it. Just add the ability to terminate fairing construction at any point and add a node there. 12:Improve fuel flow logic. Treat fuel tanks connected directly and inline to eachother as a single large tank...a "tankset". Drain each fuel-containing part in a "tankset" evenly. This prevents CoM from swinging so far towards the bottom of your rockets near the end of your first stage and causing a tumble. Fuel lines would still pull from other tanksets first. It would have no effect that would change existing designs, other than making CoM move around less. You wouldn't even need to change your design in 99% of cases. ... So thats a dozen ideas that I think would have a good effect on KSP gameplay overall compared to the amount of work required to implement. Sorry if some parts don't make much sense, I'm running on about 2 hours of sleep atm.

IMO they should just increase to atmo to 100KM, and reduce the ISP nerfs to ASL and VAC to a small degree. Id say make 360-370 to high end of chemical rocket ISP. That way, it takes more to get out of the atmosphere, more realistic scaling of atmosphere density, and allows for the balance that squad seems to be looking for. As for making the engines more realistic, I'd have to say that real rocket engines have a much better TWR than in KSP. But if all engines had a realistic TWR,the that would pretty much remove the variety of engines in KSP. Would you really care if your engine weighed 0.1T more with a difference in 15 or so ISP?

Yea, I did a bad job of explaining it. I DID mean the inverse, and failing to explain that was an oversight. Though as you said, it would encourage keeping wing surfaces away from CoM to reduce mass, the same can be said about adding parts between wing sections in the current model to prevent them from counting the wing surfaces attached via those other parts. Adding a fixed amount to distance or mass in that formula could prevent those NaNs EDIT: another oversight. This would punish small planes. Perhaps some other way or a way to grasp the scale of the aircraft its working with. In my posts, the whole reason I mentioned anything is that construction DOES matter... in an odd way relating to mass. I'm not trying to say that the 2 wings pictured should perform the same structurally. They dont, and shouldnt. Im saying that, once *I* strut them all together symmetrically and add wing spars, the biggest thing that differs in terms of performance is the mass distribution. Im not trying to dispute the idea that wingroots should be larger/heavier/stronger than wingtips etc. Thats reality. I'm saying that the way FAR detects what pieces are wingroots and wingtips results in great changes according to the order you build wings.

I hope to have a discussion in hopes of a better way for this to be implemented. If you dont like how the discussion is going, dont take part in the discussion. It's really not that big a deal, just skip the parts you dont want to read. Honestly I dont know how people get so aggravated by something so trivial... sorry I had to =) no offense intended Anyway, back on topic, I DO spread the load out along my wings. I DO reinforce my wings as needed, adding wing spars ETC and strutting to them. I DO... err... USED to buff up and partially shield wing parts I expect to take an aerodynamic pounding.* These things must be done regardless of FARs participation. That mechanic is accounted for already without adding mass according to wing construction. If adding wing mass negated for the need for all of this, that would be great. But it doesnt. I understand why it is there though, and I DEFINITELY like and appreciate the realism that it attempts to provide. However, I disagree with the methodology of how it chooses where to add the mass, and the scaling of the mass added. Thus the suggestion that the extra mass scale be distributed according to (distance from the CoL)*(Gobal multiplier). This IMO would allow much more freedom in construction methods while giving better and more predictable results. *USED to... now I add more strength/mass as the great Ferram intended. That is, IMO how this feature shines most.

Both wings are subject to the same aerodynamic forces. How I construct them is what decides how well they hold up. It is FAR that is deciding that the front outer right piece needs more strength/weight than the back right inner. And what do I get in exchange for this mass? Nothing really. This extra mass just makes that single part more resistant to aerodynamic failure. It doesnt actually make the wing stronger. Infact, in the shown example, the right wing, the much heavier one, comes apart far easier due to its unimproved tendency to flex and catch more air. Using the amount of wing surface on the other side of a wing is just not the best way to calculate it. Do it according to distance from CoP or CoL. My point is: why must I construct according to how much mass FAR will add rather than what is most structurally sound or convenient? I can distribute wing load myself. I can decide what is going to be subject to more forces myself. I can reinforce things myself. (in fact, I still have to anyway) Also, Im drinking right now so please forgive any oddities =)

It IS the same wing, but built differently.

I kinda feel the same way about this myself. I like the idea behind it but it really adds alot of hassle to the design process, and I REALLY dont like the way it got implemented. You can have have incredibly different wing mass depending on how you build the exact same wing. That and you often end up with wings denser than solid steel on some larger craft. This means wings as subassemblies are a big no no. I'm still hoping for a way to at least "set all wings to X strength" or a way to change the default strength. Fun exercise: Make a 2X4 grid of wing parts on one side of an aircraft by daisy-chaining wing panels. Now make the same wing on the other side out of four 1X2 sections. Your CoM wont even be inside your fuselage. Wish it based part weight on distance from the CoM of your craft rather than whats attached to that part.

Heavy and bulky I have no problem with. Be it new engine cores or or shifting weight from engines to intakes, what I want is to be able to control CoM instead of having it chained to a single part with placement restrictions. As for the craft that was too small, it functions as a rover, tug, resource recon probe. when docked with my mining shipit functions as a main engine and stabilizing/control fins. Very fun to use except it currently has its rapier mounted on a stick to pot CoM in a reasonable spot.

It definitely HASN'T! Having the COM farther forward helps only certain craft sizes, just moves the problem to different size craft. Try building a compact UAV with a jet engine and you wont be able to pull up. There is now a minimum size to jet aircraft. On longer aircraft where the engines are at the back, the changes HURT, as the movement foreward of the engines mass is outweighed by their increase in weight. We need a way to CONTROL where the COM is, not have it moved forward by some fixed amount. So, I stand by what I said earlier in this thread, that either your or my solution to this problem would work, and that there IS a problem.

So uh.... any idea if the new voxel system will take struts and physics-less parts into effect? If so I will eventually be posting a plane with wings made entirely out of struts...

Its probably the title.

[h=2]Repost from my other thread on this: http://forum.kerbalspaceprogram.com/threads/118102-Ideas-to-warn-of-overheating-parts Ideas to warn of overheating parts.[/h] So in many other threads, I'm seeing alot of people asking for a way to know of a part getting too hot in ways other than seeing it explode. People want to know of problems before things start exploding so... Once a part get to a threshold of heat, say 80% of the temp it explodes at, have it emit DARK BLACK smoke effects. IMO, it would be much more fun to see parts smoking before they went up instead of looking at whatever dials, right click menu ETC for a status on temp..... But this smoke should be different from regular exhaust in the following ways: -The particles comprising it need to grow from very small to large RAPIDLY. This is to allow a player to see with more detail what is overheating, while being very noticeable. Is it the battery on the side or the hull its attached to thats burning? This whole effect is essentially an arrow pointing to the part that's cooking after all. -They need to be a very dark BLACK, to be noticeable even amid the shock heading, mach effects and engine exhaust. If it looks like anything else, it wont be noticed, and wont be useful. -It need to be dense smoke to be noticeable, as ships suffering from overheating tend to be moving extremely fast. Having a puff of smoke every 100m isnt gonna warn of anything. This means rapidly spawning particle effects. To prevent loss of frame rate, they also need to be short lived. -They need glowing orange sparks in the black clouds. This it to make the effect useful and visible in the black background of space. Of course there wond be any real glow effect, just orange sparks on the sprite used for the particle effects. -Optional: Add more and more sparks and even flames as the part gets closer to overheating. And... that's it for now. Any one got other/ better ideas? It's the best i got on short notice, that doesn't break immersion, and still lets you see what part is having trouble. Other solutions I've seen: right-right clicking every part looking for trouble spots would be tedious and doesnt help you if you dont ride around with right click menu open.... right click info would be useful, but not as a warning of impending doom. Hearing an alarm going off would let you know something is overheating... but just that... *something* is overheating. You still have no ideas whats overheating and you have no clue whats if the impending explosion is tolerable and to keep going, or would be catastrophic, and you need to be trying to get your kerbals out alive. And of course seeing an explosion isn't even all that informative until you hit F3. Unless your craft is already falling apart and then yo are just cussing anyway. Placing bacon outside of craft. While delicious, it is hard to retrieve bacon in situations that allow for cooking. Lemme know if you guys have better ideas for warning of impending thermal doom. Unrelated, but still important to me, since it got worse in 1.0 : http://forum.kerbalspaceprogram.com/...t-engine-tweak Bump it if you agree!

So in many other threads, I'm seeing alot of people asking for a way to know of a part getting too hot in ways other than seeing it explode. People want to know of problems before things start exploding so... Once a part get to a threshold of heat, say 80% of the temp it explodes at, have it emit DARK BLACK smoke effects. IMO, it would be much more fun to see parts smoking before they went up instead of looking at whatever dials, right click menu ETC for a status on temp..... But this smoke should be different from regular exhaust in the following ways: -The particles comprising it need to grow from very small to large RAPIDLY. This is to allow a player to see with more detail what is overheating, while being very noticeable. Is it the battery on the side or the hull its attached to thats burning? This whole effect is essentially an arrow pointing to the part that's cooking after all. -They need to be a very dark BLACK, to be noticeable even amid the shock heading, mach effects and engine exhaust. If it looks like anything else, it wont be noticed, and wont be useful. -It need to be dense smoke to be noticeable, as ships suffering from overheating tend to be moving extremely fast. Having a puff of smoke every 100m isnt gonna warn of anything. This means rapidly spawning particle effects. To prevent loss of frame rate, they also need to be short lived. -They need glowing orange sparks in the black clouds. This it to make the effect useful and visible in the black background of space. Of course there wond be any real glow effect, just orange sparks on the sprite used for the particle effects. -Optional: Add more and more sparks and even flames as the part gets closer to overheating. And... that's it for now. Any one got other/ better ideas? It's the best i got on short notice, that doesn't break immersion, and still lets you see what part is having trouble. Other solutions I've seen: right-right clicking every part looking for trouble spots would be tedious and doesnt help you if you dont ride around with right click menu open.... right click info would be useful, but not as a warning of impending doom. Hearing an alarm going off would let you know something is overheating... but just that... *something* is overheating. You still have no ideas whats overheating and you have no clue whats if the impending explosion is tolerable and to keep going, or would be catastrophic, and you need to be trying to get your kerbals out alive. And of course seeing an explosion isn't even all that informative until you hit F3. Unless your craft is already falling apart and then yo are just cussing anyway. Placing bacon outside of craft. While delicious, it is hard to retrieve bacon in situations that allow for cooking. Lemme know if you guys have better ideas for warning of impending thermal doom. Unrelated, but still important to me, since it got worse in 1.0 : http://forum.kerbalspaceprogram.com/threads/92819-An-arguement-for-a-simple-intake-jet-engine-tweak Bump it if you agree!

Wow, I really like those ideas... esp the head pipe... You should make another thread asking for radiators AND those other things... would be a great addition to the game. Also... why not have a radiator on the shaded side of existing deployable solar panels? then u could just modify the model/ texture and get the job done. As for fixed panels, just make a retexture of a radiator. then its just 1 added radiator part instead of several. But I really like that heatpipe idea... would be great to pipe heat generators directly to radiators!

Wow! Great too see FAR is not only coming back so correct stock erro, but being improved as well! Glad to see the best mod in the game getting better, and THANK YOU for all your hard work! How do voxels handle air intakes? Their aerodynamic properties seem to be far from what the shape of their model suggests: Tube (actual) vs Bucket (model shape) Jet engines... will they still have a flat reduction of power? Wings: will we still have the same strength-mass slider? Oh, I also heard someone say something about hyper-maneuverability... Yea, I got nothing to edit videos with... so I dont have a way to take out pandora in the background... or the crash! XD EDIT: Ugh they reallly messed up jet engines... I keep asking then to transfer some weight of air breathing engines to intakes but they just added mass to engines instead =/ http://forum.kerbalspaceprogram.com/threads/92819-An-arguement-for-a-simple-intake-jet-engine-tweak I brought this up alot but I cant keep ressing the thread =/44

We DO have alot of LF only tanks already.... we use them for jets

Also, they kinda almost sorta confirmed that MK3 wings will be able to carry fuel AND oxidizer! Note that Maxmaps said the pictured shuttle's only fuel source were the wings? You see any jet engines on there? nope, all those engines need oxidizer. Doubt they would showcase a non-funtioning craft.