vv3k70r

Thank You! Robotic parts are locked after reaching angle. But after transport they need some adjustment. They are used only in low gravity, but I found ways to deal with da Mighty Kraken, here is spider during refueling using pipes also with robotics: More pipes packed on site - they come in packs:

11yo. But no - current school is more about equality and other political stuff. Question about "why Sun shine" turn out to be "because it is hot" (good) and after questioning why hot he came up with "volcanos?". So when we reaction wheels came up I took him to press deparment, blowed some dust from old 670kN excentric press I have and started it to show what it is all about with motor, flywheel and way of distribution for momentum. Question in school should be answered before they are even asked. It works well in factory and workshop - they get really fast when they do the job. In daily life we have aerodynamics and gravity to put a given threshold in oposite forces so things stop spinning, moving and so one. In vacum situation is diferent and only big vacum avilable for me is a soldering stove (I do not know a propper name in english) which make quite complicated to show what is going on inside - cables for camera will not go throu two layers of chassi. I think it is good enough, meyby stifnes and struts are overpowered but KSP works - there is no reason to fix it. Question who is the target of such a game. If old nerds - fine, but to explain all this complexity to kid where any mistake lead to a failure takes a while. You never know what is in kids imagination. Meyby there should be some stock tutorial machines that work and tutorial for them teaching about flying, landing, manouvers starting from planes of diferent configurantion between propulsion, COM and lift. Because now You have to design a plane to fly and this designing proces is quite unintuitive when You do not fly. Meybe... I do not know. I do this that way. Designing is complex so I help with this, but flying is on his own.

Some more struts would do the job, toque of engine against this big tail screwing the plane:

And this little white pixel above blue arrow of aerdynamic force is the Minmus. (flying angle to load power) Minmus for sure:

There is a lot of basic mechanic that kid do not know about. So it includes reading. I treat such games more like a reason to educate kids. So I like the aproach KSP deliver because it is acurate to my needs - there is anough reading, enough playing and enough extra questions that end up with more reading and counting. If we like we can just waist some monoprop right away and consider it desaturation. And the kid wilk ask "why" which lead us to enother "why" and so on. So You have to make a tutorial explaining why and how work aerodynamics, then thrust in atmospheric presure, and drag, then thrust in low pressure, then aerodynamics in low pressure and high speed, then thermal issues, them thrust and directions in vacum, then heat in vacum without convection... I think as it is now it is balanced enough for kids to play without considering any magic power that keep all this together. Good enough for my pourpose. Anything better would be a more mature simulator but it has a narrow market. I have an example of one of such "why" - "why I do not have electric power" which came to how solar panels works, how they are manufactured, from what kind of silicon and purity, how much energy does it cost, why the Sun shine, how it works, what are cycles, what is hydrogen, helium and so on, what is a table of all substances, whay they are numbered after protons number, what are isotops and isomers, what are electron layers, how to count them, what is state of electron and so on. Somehow we ended up in technical civilisation where kids in school are not teached about how all this works because teacher must be cheap. And cheapness came with consequences.

Obviously. To calculate nbody You have to read in every body from the list for every body and stack vectors to execute positionchange before You execute next loop. There is a lot of room for exploits because some asteroids have a significant mass that can be dropped during gravity assist. I sugest to use massless Sun (just jump over it in calculations) and bodies would draw beautifull epicycles around mass centerpoint. There could be no reasonable, exploits/bug free solutions for curent computing power avilable at home for playable game pourpose.

People have jobs beside playing?

Look at Q&A - most do not get why rockets wobling. There is many factors to consider just during design, if there be more factors complexity would move market far to the edge of belles curve where is not much people that can handle it. Now we in kind of a crisis so these people have some free time to spend on intresting game, but it would not last forever. It will make very small market. They are very good as for me, but I asked kids about it and read-understund-execute exactly as stated is something that expect reading at first when they expect playing game.Orbital mechanics was hard to grasp for real pilots in early days and I understund my sons stories about friends that targeting da Mun and be disapointed when not reach it. They consider - game is cheating them, it dosent work properly, it must be a bug. Customer expectations. Complexity. Someone have to implement all of this and someone else have to pay for the product.

Because they are lightweight, kept in shape by preasure and struts. When they are empty they are in much lower pressure. Otherwise You can use thicker material and it bring some weight. They do, ther are more like baloons. If You empty them and cut suports (struts are part of it) they just colapse. Be happy that games phy do not consider TWR around 12 as a reason to crack the tanks after ignition. And most controls just to colapse. Because they are unbalanced. You designed rocket - You are only to blame for wobling. You make more - You learn. Aeroplane is hang in the air by the wing. They are quite flexible if compare to let say... bridges?

Can they guarant any if players start throwing asteroids? It is why it is playable. Realistic mean over 10k dV to get away from homeplanet. Players are significant chaos factor. Most simulation I runned where peuudo stable when almost empty (like our world) or after changing some values (to scale it down) it was hard to find starting state that could deliver anything pseudo stable. Of course there could be some phy cheating making static keplers adjustment (mostly adjusting rotation to speed and distance of the body) to dynamic state, but players will notice that and exploit for magic gravity asists. And it is not that instability colapse it in long term - when domino starts it go fast and disasemble whole system. Mostly throwing everything away after passing near central star. So if they would put anything intresting like binary planet (say planet and moon of similiar mass) there would not be any room for dynamics. Pin it to rails and forget about physics. There is a workaround I used - I justr throwed gigantic number of celestial bodies and wait until it get stable. Most were thrown away, Oort has formed, asteroid belts has formed, but distances were realistic (just more eliptical orbits), so playability would be hard. Let say it is a perfectly adjusted manouver?

It is what I took in consideration. Reacion wheels just keep expense in monoprop in reasonable area. Most people could not get to orbit without this overpowered reaction wheels. Game would be propably not so playable. Already we can chenge their values to more resonable range of result and in such a case would be not much of use for them in the game for thing we are using them now. And a lot of micromanagment after docking. I guess most scrap docked on orbit by players are not well balanced to make any reasonable manouver with thrusters placement as it is. Most people would not grasp how it works and why that way. There be a lot of Q&A about it "my craft lost control!". Using momentum in both dircetion (of rotation) on given axis with accelerating and slowing motor could be hard do explain for most people. And planing how to set it for future, expected manouvers is a job for engineers - it is not much playable. Depend which way - if we get to every technical detail of real solution for every part of the craft it would not be a game any more. But could have educational value. If we add how long and how much diferent bearings can handle it would not sell good. Always! When I showed my son that striping off his rocket from most of srb he placed there give him higher dV he start to understund what TWR is about and why spacecraft must be light.

I' moving base with spider crane: And coasting probes home cheap:

Including my son around 638 hours ago say steam. Somwhere in september 2020?

I had to move base on da Mun to crater with ore and my first, clumsy rover even with tractor would not do this (or it would take around 12 hours of running a rover with lab on earliest wheels), and there is some more not flyin stuff from old base. Aiming for landing: Scientist didnt stop research during transport. Crane is delivered to orbit with legs together, then in microG unlocking hinges, spreading legs to proper position 90-90deg, locking and is ready to fly to da Mun. Cargo crawled until the crane. Get attached. And had a ride. With graphic turned almost off because phy start to have needs because of number od dynamic joints. File: https://steamcommunity.com/sharedfiles/filedetails/?id=2314346013

Before I launched this hydroplane I meet some more Mun craters (only mountain one left) and without any other usefull tech in range (with most basic aicrafts up to afterburner) I took heavy electric motor (and seen the big wheels - I understund CEO with his "why?!"). Big electric motor get 24blade atached, and of course I took same countertating. Then troubles began. It need bigger fuselage, but floats also need to be bigger. Powert of the engine turn me to something resemblin delta shaped jet with float and as far I know hydroplane jets are bad idea. Tail cones showed to heave side drag in water that colapsed whole idea. I use empty rocket fuel tanks with nose, give to much battery during balancing it (at least half of them could be removed now -18k electric power is a lot, specialy if during daylight it dosent use them) and after fiting it with pv bookkeeper seen the price and start asking questions about sanity. Of course at the begining there were problem with balancing it - it fly good at low speed or high, to take of from water was a diferent story. I ended up with big wings and floats configuration that allow to easily land on water without any suspicion that it crashed and go on water building speed very fast same way. It floats good. But size of the wing restricted speed to 200m/s and adding pv to 180m/s. Taking off is just about seting the deployment angle of 48 blades on rotors by main throtle (rpm fixed), pushing deployment (AG 3) and after 40m/s it will fly, then push 3 again, adjust deployment by throtle building speed and fly. It roll corectly (as for hydroplane -floats are a bit of issue). On water same procedure, just cannot build speed so agresive, but press 3 and its all. File on steam: https://steamcommunity.com/sharedfiles/filedetails/?id=2314337961 Most of control surfaces is just to be deployed, they have no use during flight, because total surface on agresive manoufers with this engine build G that disasemble it.

W can mimic the desaturation just by spending monopropelant if we like. So wheels could drain a insignificant amount of monoprop all the time or have a constant desaturation, or have a button to do that at one move, or turn the vehicle "randomly" without it when they set back or... But there be lot of micromanagment so it would be automatised and playability of such a complexity would decrease or be unnoticed when automated. And if automated there be Q&A why reaction wheels eat monoprop.

This issue came from adapting to screen resolution. Pressing alt+tab is asking for trouble. Sometimes it change, sometime not (I guess it depent of using graphic to display video in browser, but it is just a guess). Workaround is to adapt screen resolution before You start game like dos games from the past. I keep two setings for two configuration that happen, and if I'm annoyed just restarting the game. But never seen problem with icon displacing.

I programed some simulations wiht n-body, to set a long term stable planetary system You get a very empty system (like our) or there is a lot corection behind the phy to keep it on track, or it is not stable before and after. Every orbit is in long term chaotic and it came from chaotic state. Current ilusion of "stability" is just an event. I guarantee that pleyer would play back and forth such a system and see diferent path of timelapse.

Did You stop the engine before chutes?

If You add control surfaces it will help, specialy if You add some on the nose too. How is Your TWR and its dynamic? Do not put so many draging stuff on the top of the rockeet if You are about to loose propulsion in atmosphere. Rocket was suported by air. On 25km there is not much of it and You have to depend on thrust to grab this air faster. Rocket You show can be stable only on very high air speed. Rockets are made for high speed. There is nothing wrong with it. Just keep prograde when You are get high and keep it. And keep building speed. When You stop and You in atmosphere it will flip.

COM could be shifted, and it is in most real vessels (mostly thrown away for adjusting angle of atack during entry in atmosphere). This is matter of computing. Early RCS were overpowered because of asymptotical corection to achieve. PID today and in early days are on completly diferent level. We were speaking about manouver nodes. In any case the point You set manouver with burn time before and after would never be reached - it will be passed around. So if it is more or less around because of gimbal dosent play much role if You can cut complexity of the vessel. If You do a manouver we can gues You need a thrust. If You will have a torque just shift a bit COM (there is lot of real solution do do this), give a very small thrust, turn it off and wait for corect pointing of the main engine. It will not spot turning around with engine turned off. Absolutly yes. And in real case - at least 4 of them and thrusters. Because our world is not so perfect as KSP and sending a rescue mission to service some scrap far away is almost never an option. But in case of travel (as for misile) You can get away just on the main engine. It depend how You value Your craft. And its crew^^

Size of the engine and it technical purpouse is mater of nomenclature in design. In a perfect world there is no need for any other engine then one. It could be pointed any directon? We trying to solve this issu making engines that can achive something like this abstract of perfection. Using any other source of thrust is just technical solution for imperfect, avilable tech. It is not only engine - computing power, telemetry, actuators, sensors, valves, procesing speed on this axis. With procesing speed is an issue of energy suply, with energy supply came issue with cooling and so on. Coupling lot of engines was a solution, and it will be again when we build something that size there be no other avilable. Redirecting asteroids could be one of such COM problem to solve this way. Other way we can land, attach, add vector, jump to enother position, attach, add vector and so on. Who knows what kind of solution would be easiest to achieve for next generetions? And there is more like reaction time (delay to start, delay to stop), low temperature that allow to set there direct sensors, reliability and more words on "r". I suspect it is made for easy-in. Game troubeling players with real technical issues coud not sell that good. I suspect it is reason why reaction wheels are overpowered (I'm now at the end of trip around Mun on reaction roller with poor Bob inside - he visited almost everything from pole to all big craters and some smaller). Who would play with nonresponsive space ship? It would be just a bad game. If You have nuclear engine in space burning fuel in any chemical reaction is a pure waste of dV. Nuclear engine is a tool for taking combustion engines to place, where nuclear would not do any usefull job.

N-body problem is hard to implement in a game. It would not be much playable after a while. So rails are implemented in game. In game You can do something that resemble this cycle in its simplified mechanics for some loops. But in game it would not be a good idea as it is in reality.

It could be that part lost it root/parent node (whatever games call it). It happens when You fulfill assigment /part of assigment combined with staging. You can edit it in save game manualy or use KML to open Your gamesave - it detect those problems automaticly and allow You to fix them. But without fuel or engine You propably need another rescue ship? I hope this is funny part of the game when things dosent go acording to plan.

Misunderstanding. I refer to that every vesel use external force (against environment) to change orientation. Plane, car, ship, bicycle, spacecraft. During this change have a thrust vector and is not corecty oriented. It dosent prevent us from making manouvers. If it is main engine it is still not a problem. I think that idea that reorienting do something bad to manouver base on the node placing in KSP where changing orbit dosent update manouvers results. But then we are about to dig how we estimate position by clock diference from given telemetric nodes and how to navigate using clock (as for example in dark or underwater). On the begining of space flights there were no reaction wheels but manouverability were present. If You see the manouver mechanics time is important, because burn have a duration and during this time it cannot be corectly oriented as for 0 time burn. Same factors aply to any control system using whatever force given to outside of the vessel or recived (as aerobraking in KSP). For most people it is easier to grasp idea of 0time burn node on direct position because mechanics is much easier that way to explain in formulas. When ther is a curve things starting to be a bit more complicated. I guess that misunderstadnign comes from idea of perfect manouvers aginst unperfect manouver planing in KSP for such ocasions as using whatever engine is main for changing orientation. dV aplied to orientation change against orbital velocity dosent afect orbit on any important factor for transportation (for sync orbit it does). I docked vessels using main engine - is there any more precise manouver? If we refer to 3d game diference between those two solution is rotating pivot without moving against reference position to the frame (celestial body) any other then orbital speed. The other of two is moving this pivot during manouver when You rotate it. Try both, save 2 game saves, look at the diference in position and rotation in persistent file - it have many digits, diference would not be much.