kcs123

Welcome to KSP forums. This symmetry bug dates several KSP versions ago. Have no true solution, only workaround of this. One option is to inverse rotation on mirrored part in VAB/SPH. Other option is to break symmetry on purpose. Additional reason why you should do this is if you use stock wheels/legs on moving part of rover, it will autostrut to mirrored part. So, trick that can help you with this is following: create one side of moving parts as you already did and place it in symmetry copy mirrored side of IR parts (ALT + click) and put on side not attached to craft remove parts that you placed first and remove symmetry option re-attach first placed IR parts without symmetry attach mirrored copy on oposite side without symmetry too Now you can set rotation independently of each other, wheels would not autostrut on mirrored part, only to grandparent/heaviest part on one side of craft. Creating parts in a way that you can place on attached node instead of surface attaching helps a lot to avoid CoM/balancing issues with non-symmetry placed parts.

Most likely you have missed something silly trough install process. Not sure which, though. There was several similar reports in past and even with latest one problem was solved with re-install.

Nope, it will not work, unless you recompile source code for yourself and change necessary files. Or until ferram publish official supported FAR release. However, there is forked version with removed ARR licenced files that work:

Try this forked version instead (from OP): https://github.com/Rafterman82/B9-PWings-Fork/releases/tag/0.71

I just copy-pasted pieces of kOS function, yes it is meant to explain things for beginers. LOCAL command is used for declaration of variables inside of function whole thing is under spoiler section: I created that piece of code as function and have it in library that can be used in all kind of situation. It is meant to be most univeral as possible. As you can see, I have encountered in similar problem as you have with fliping rocket in undesired direction, that is reason why I have "MaxFallAtmo" parameter for vertical velocity. So, if previous calculation gives solution that is much higher than what is considered "safe" for rocket to be able to steer, it will give max safe atmosphear velocity that can be properly handled instead. I'm using info from that function in main script that handle steering and engine throttle with PIDs. It is less efficient due to higher fuel consuption than it is necessary when you have everything calculated accurately 100%, but it does job well enough for rocket to survive landing. So, answer to second question, what direction you should choose trough landing is that engine should point away from the direction you want to move in (generaly speaking). With such big rocket don't rally only on fins for steering, use it in combination with RCS too. Real life falconm rocket also use them, although it is not so obvious from their launch/landing videos. I usualy use RCS trusters from B9 mod instead of stock ones. It is hard to give you exact solution that will work in all cases, so you will have to adjsut things a bit depending on celestial body with atmosphere, rocket that need to land, suborbital or orbital trajectory, etc. But with a bit of trial and error it can be handled. To mimic space X landing, when booster is separated from upper stage, while still at high altitude you need to bleed out all horizontal velocity and a bit more to go in oposite direction toward launchpad. You need to overshoot it to some amount because drag forces would kick in and you will also reduce horizontal velocity while maintain "safe" vertical velocity at same time. What I'm doing at this part of landing procedure is to lock steering to retrograde while watching to maintain "safe" vertical velocity trough PID/ main engine throttle control. Because of being on angle instead of 90 degree, rocket also bleed out horizontal velocity too. That is actualy desirable as you want on final aproach for rocket to be completely vertical, so it does not tip over when you shot off engines. IIRC RCS can be used separatly from main engines and regardless if are used for steering or not. Use that info with grain of salt, though, but I think it is possible to use kOS translate RCS feature along with them being lock for steering too. RCS should be strong enough to correct small errors in impact point as you aproach launchpad. Impact point can be obtained from kOS orbital values (where ship would be at some time with current trajectory). From that position you can get long/lat on clestial body and compare it with desired landing/impact point. Of course, because it does not take in account drag from atmosphere it will change all time, but you also can re-calculate steering all time too and make necessary adjustments. I recommend fine tuning steering for exact precise impact point when you bleed out most of velocity and rocket is subsonic, so atmosphere forces are managable to handle.

And the best thing about kOS is that you don't have to 100% accurately calculate landing spot and impact time. "Proper" way to calculate it would be per ship, to know exact coefficient of drag for ship or vessel. Cd again depends on ship shape, angle of attack, atmosphere mach number, atmosphere pressure (for fluid density calculation) atmosphere temperature that also influence mach number etc. Have also take into account ship mass that influence kinetic energy, that need to be drained at impact point if you want to use ship more than one time. And ship mass also change over time as you use rocket fuel, available thrust change too and whole equation become even more complex. Even when you get proper equation, considered every possible thing that influence landing point you can get some random event during flight that add some error in equation and that you could not predict before. So, how to do it then. Well, "dirty" but much easier way to calculate impact point with kOS would be to re-calculate impact point and time on each second of flight, instead of calculating it only once while ship is still in orbit. Fortunately, kOS and KSP game world can give you more than enough data to calculate it good enough on each game frame that makes thing a lot easier. Instead of pre-calculating everything, start with more simple landing script and extend it later on. For start, disregard some things in equation.Start with assumption that your ship killed all of horisontal velocity and you are on Ap with zero vertical velocity. For first script assume that celesital body have no atmosphere too. Next assumtion is that your ship is perfectly oriented, so engines always face downwards or retrograde. Now, instead of having complex equation you have simple free fall equation. Pretend for a moment that we don't even know free fall equation. What we know is gravity constant on that celestial body that would accelerate ship to the ground. Except, not even gravity acceleration is constant. It changes too as ship fall down to surface, not much, but significant enough to cause errors in calculations. Good thing is that kOS and KSP game world give you enough data to re-calculate gravity acceleration each time you need it. Already prepared for kOS script: local Body_g to SHIP:BODY:MU / (SHIP:BODY:RADIUS+altitude)^2. OK, we now know gravity acceleration, with assumption that it will remain constant during the fall or landing you can get equation for ship (vertical) velocity on any given time: Velocity(t) = Body_g * t + start_velocity When you integrate above formula one more time, you will get equation for distance, that you already know from ship sensors - it is current altitude above impact point. With all that you can get equation for fall time. // we can use simplified equation if starting velocity is zero set FallTime to SQRT((2 * FallAltitude)/ Body_g ). Knowing falling time you have to calculate backward, what would be velocity at that time. You need it later on. Now, consider ideal vertical landing, what is ideal situation for ship to survive impact and burn least fuel as possible. Ideal situation would be that vertical velocity is zero and force from engine thrusts is equal as force from gravity but in oposite directions to cancel each out. Ship should also stand on it's landing legs too, so it would be safe to shut down engines on very next time frame. Sir Issac Newton told us that force is calculated like this: F = m * a If you trust that his equation is correct then you can calculate both forces, from body gravity and from ship engines: local CraftWeight to SHIP:MASS * Body_g. local CraftMaxThrust to SHIP:AVAILABLETHRUST. You have also need to put in consideration what kind of info ship sensors would provide. In "normal" velocity/distance equations distance at zero time frame is also zero and velocity is positive as time pass. Ship sensors will give you oposite, as ship falls down, vertical velocity become more negative as time pass and you start with positive altitude that become lower and lower down to zero. With that in mind Fall time calculation looks like this: // On this line is NaN if equation under SQRT gives imaginary result, or divide by zero occur or any other undefined value // happened also if cheated to Mun orbit with engines off, could be due to celestial body changes between physical ticks or number becomes too small if (MAX(0,(ship:verticalspeed^2 +4 * (((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)*FallAltitude )) > 0) and (CraftMaxThrust > 0) and (Body_g > 0) { set FallTime to -1 * ship:verticalspeed/(2*(((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)) + SQRT(ship:verticalspeed^2 +4 * (((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)*FallAltitude )/(2*(((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)). } else { set FallTime to 0.1. }. Again, above works only in certain situation, that ship vertical velocity is either zero or negative, ship TWR is above 1, so you can choose proper solution of quadratic formula etc. You need to put that in consideration for the rest of script code, so it does not throw errors in run time. In example above, if you put negative number in SQRT function, script will throw error, so you have to consider this. Why all this written above ? We have started with most simple situation, but now you also can tackle down situation that also put in consideration that ship mass, body gravity and velocity change over time. You don't need know what kind of situaton was before or what would be changed on the whole landing time, all you need to know if thrust from ship engines are powerful enough to reduce vertical velocity to zero and also capable to maintain it at zero (equal or greater acceleration against celestial gravity acceleration) at the moment of impact. Now, things are much more simple to tackle, all you need to worry during landing is to not allow vertical velocity become too high that ship engines could not counter part it. All of that above is not to give you ultimate solution, it is rather a starting point to think in different way and come to solution even when you don't know complex equations. It is up to you to extend this info further, instead of ship pointing 90 degree all time to counterpart vertical velocity, you can put in consideration that is on some angle and instead of full thrust force that engine can provide you can put only vertical fraction of velocity vector. In case of celestial body with atmosphere you not need to worry that engines would start too late as drag force would only help engines to slow down ship and when you are very close to the ground it can be also disregarded. But you need to worry about it depending of ship shape/design because when your velocity is too high in atmosphere then your ship can flip and main engines no longer points in desired direction etc. I have also extended pieces of code shown above to put in consideration different height of landing legs or ship:alt:radar value, different veritcal velocity that is "safe" to maintain in atmosphere without fliping rocket in undesired direction. Instead of landing imediately, I prefer to hover rocket 20 m above ground and switch to semi-automatic landing mode that allows me to choose better landing spot and so on.

Can't afford to buy drone and my PID tuning skills are not that good to be able to contribute in this. However, some time ago when I was looking to improve my kOS scripts, I found decent arduino AutoPID library. Some pieces of code might be worth to study.

Recently I saw this kind of error in few other forum threads on various mods. I was not reading in details what is related with this error and no longer recall threads where I readed about it. I think it was from one mod that @linuxgurugamer maintain, but might be wrong. I apologize if I pinged linuxgurugamer without reason.

I should correct myself, you get NaNs in flight if there is no other parts involved that have proper lift/drag calculations. But, without proper data you would definetly get wrong calculation of lift and drag, though not always noticable as it become totaly broken with NaNs.

No worries, community will have to wait. Personal health is much higher priority than waiting for couple of more days for update. Wish you fast recovery and much better luck for remaining of following year.

Yep, thermometer and barometer were at starting point in UBM or very close to start, can't recall from top of my head right now. That, and most simple rover wheels to be able to run around KSC and grind few science points if you are stuck with something is one of reasons too. Maybe to create MM patch for early probes to have sligtly more electricity and built in antenna, just for close range 100-500 km or so. That would solve issues in early hard career mode with limiting amount of parts on crafts. First few flight should not mean to be sucess, but rather to be able to grind science points in upper atmosphere with thermometer/barometer, transmit that info on KSC before craft is smashed on the ground. That should give you some few points to unlock next nodes and with those to actualy achieve first milestone goals. IIRc, similar conversation with Yemo is buried somewhere in SETI/UBM thread.

That might work. Tier 2 is not way too from start. But, yes, I have liked being able to create simple aircraft early in career for ability to grind few science points and money if stuck for some reason and not being able to put rocket in space and/or orbit trough first few milestones. UBM was created with GAP in mind too. Might be good to hear opinion from @inigma on that topic.

There is a lot of interest, I would like to do it too, but unfortunately real life commitments does not give me enough free time lately. That is reason to hesitate doing it, I can't tell how much time I would have to create it and let alone maintain it later on. Sharing ideas and pieces of pseudo code from time to time is best that I can offer for community at moment. Lurking those forums and sharing info to help other in best way I currently can.

No worries, I have not much free time for KSP recently, so no rush with this. I almost exclusively use wings from B9PW for aircrafts. For rockets, stock wings and fins suffice for me on first rocket stage. Other users who use more wings from APP would benefit more from your configs. Thanks anyway for this. Might be good idea to send PR with those configs on APP github when you get time. @dkavolis, yes I know about that blender/wing info that need to be created for FAR. However, have no idea why cockpits and fuselage a-like parts from this mod cause issue. Tried to compare configs from APP parts with similar parts from other mods, but that ways not give me any clue what kind of info is missing for APP parts. That leaded me to speculation that something with coliders is different, but again have no idea if coliders can be handled trough config files or need to be handled in blender and exported for unity usage. Thanks for opening issue, once we know what cause this, it will be easier to create proper config files or MM patches later on. EDIT: I see that you try to handle ground effect in FAR. IIRC Ferram was not handling this because it would not be accurate when you are near sloped surface, like taking turns very close to mountains, for example. Or if you are on some angle of attack instead of perfectly normal with wings against ground/surface. So, I was thinking if it can be handled in similar way as shadows are casted/rendered. Not exactly shadow, but whole code should be similar. I will try to explain in semi pseudo code. Set a fake light source above plain, distance should depend on wingspan do raycasting only on each frame downwards to detect if you are near ground, so ground effect calculation does not need to be calculated at all. Raycasting is pretty cheap on CPU usage, so that alone would not cause performance issue. Have no idea what would be proper height when ground effect calculation should start, more info about it is needed, but my guess is that is same as wingspan length or half of wingspan length. instead of calculating ground effect from wings geometry, use projected image on surface, or fake shadow from that mentioned "light source". Probably not most accurate, but should be much closer to real thing when comes to mentioned issues near mountain or sloped ground for more simple calculation and being easier on CPU load, you can assume that whatever raycasting result gives you, that area below aircraft is perfectly flat for that frame of calculation. Area for calculation on surface where "shadow" is projected should be simple square of wingspan X aircraft lenght. Probably not the best way to do this, but in games you need to fake a lot of things. Of course that "shadow" is not need to be rendered on screen at all, but calculation is very similar. I was thinking about it as watching aircraft shadow at noon while aircraft si on the ground. Shadow from wings is biggest when aircraft is close to the ground, same as ground effect lift force (assuming that aircraft is moving with enough speed). As aircraft climbs up, shadow becomes smaller and smaller same as ground effect too. I hope that I was able to describe my thoughts properly, becasue english is not my native language.

@dkavolis, does you know what things breaks FAR when you use parts from Airplane Plus mod ? I know that wing parts and control surfaces need extra piece of code in config files, for FAR to properly calculate lift. But, strange things is that even if you use only cockpit and fuselage parts it also breaks FAR somehow. Anyhow, that was issue few KSP versions ago, haven't tried yet if same things happen with your forked version of FAR and latest KSP. First sign that something is wrong when you use those parts is that in SPH/VAB editor you get stock balls for lift with arrow. You should see jsut blue ball without arrow with FAR. Another issue is that while you still can fly crafts with those parts, drag is not properly calculated, you got NaNs in FAR data window while in flight scene. Nothing is catched in log files regarding this, so would be necessary to add some debug messages in code to be able to catch this when something breaks FAR calculation.

You should backup your modified files in some folder outside of installed main KSP folders, so you can copy that over your new install when KSP updates. Also, it is wise to keep main KSP install files unmodified. Just copy whole KSP folder elsewhere, outside of steam folder if you use it. Then install mods over that copied instance of KSP. That way, nothing will be overwritten when KSP updates and your mods would work properly for that copied KSP version. Considering ARR licence, that is only option left, to modify and use files by yourself for personal usage, without any distribution on internet. We can only discuss what need to be changed to make this to work, info about it already exist in this thread, just search for it. And on top of that you can use UBM extended config files.

Yep, CKAN saves a lot of time that can be used for playing a game, instead of following various install instructions. But, while it is designed to "fool proof" as much as possible, you have to be aware of CKAN limitations. Meaning, when you often re-install some mods, if some mod create config file or some other file after install, when you run game for a first time, CKAN would not remove mod folder with additional files in it. Due to MM and how it recognize by folder names if some mod is installed or not, it can lead to unproper settings in game database that MM alter. 99% of time CKAN does job quite well, you just have to be aware of mentioned limitations. Even when you get into some issues, most of time you can easy repair things by yourself by using list of favorite mods. Just create list of favorite mods, uninstall everything, check gamedata folder if there is any leftover folders that are not part of stock game, delete those by yourself and install everything again trough CKAN, using mentioned list. CKAN is smart enough to re-use previously downloaded mod files, so you don't need to redownload them again, just re-install again. Of course, there is also some unproper installs from time to time, when mod author or someone else that maintain CKAN metadata files make some typo or create something that does not install files as intended. But, that kind of things can happen even if you use manual install, if you copy some older version of mod that is in dependency list or similar. And it is spoted by community and solved quite fast, mostly you have to just wait for couple of hours and re-install mod again trough CKAN.

Welcome to KSP forums. What KSP version you are using ? Links from this trhead are way outdated by now. You could have more luck with this: Though, like I said in previous page to someone else, you need first to attach wing on craft, then hower mouse over placed wing to "highlight" it and then you can press "J" key for B9 menu to pop up. There also might be issue with screen resolution, for menu to pop up outside of visible desktop area. Just wild guess as those are most common mistakes.

B9PW licence allows changes and forked version, as for FAR there is new fork FAR version and thread with removed ARR stuff, so you are good to go wit that, no need to worry about licence for FAR. And people can choose to use FAR or not along with PW.

Game breaking changings are never pleasant, but it is necessary at some point of development if you want to improve existing features and add new ones. Considering pros/cons, it would pay off to bite a bullet and start new game when gamebreaking version of mod drops. I start new game with each major KSP update or continue playing older version of KSP and mods, so no huge damage on my side.

From the OP of BDArmoury mod: Vessel mover comes along with BDA. Don't know how it work as standalone, would it cause issue or not. I'm not sure if Physics Rabge Extender is dependency of vessel mover or not, though.

@dkavolis, I agree with above. Even if that be a short period of time before ferram respond about future updates, it be much less of confusion regarding bug reports, does it belong to original or forked version of FAR. I assume that it will be easier for ferram to distinct questions that are related to original FAR mod vs forked one. With replaced ARR content, there is no longer licence restriction too. Just made it clear in thread title and in OP post of new thread that it is forked version. Once that is done, folks that maintain CKAN, like @politas, @HebaruSan or @linuxgurugamer could help you how to publish it trough CKAN. Ferram seems to be very busy, it might pass several months and new KSP verion hits sooner than we got any response. Otherwise, I would always advice to a bit longer for proper permission of original mod creator.

You have given me a good laugh . Very first thing after windows install for me is to enable showing file extension as well as hidden folders on machine. Almost forget about it when I need to work on someone else machine. And I can only add that is not only one useless "feature" in windows. List goes on and on. Each time I encounter on something similar I keep wondering if they using drugs or something when they deceided to made things works like it is. One of worst things is that they change location of system critical programs after each update, like "run" shortcut or access to control panel for example.

You need to pay attention when comes to "just recompile" FAR. You need to change KSP version number in source files, otherwise FAR would disable itself if you attempt to use it on newer version. But, MM only look for FAR folder if exist and by that it "think" that FAR is installed and run properly. Modular flight integrator as well as other mods are not aware that FAR disabled itslef and in attempt to apply MM patches that are made for FAR you got various kind of errors and wierd issues. Just something you need to be aware of when you recompile source for yourself.

When comes to coding ? Answer is simple - "everything" can go wrong. It is just a metter of timing, when it will go wrong at some point