kcs123

Some real life Infernal Robotics: Now we just need to wait until someone recreate this in KSP

You are wrong again. Jets engines works much different in KSP 1.x.x compared with KSP 0.90 That is reason why they were no longer nerfed by FAR. Jet engines reaches maximum thrust as you have more speed and engine thrust rapidly falls when you raise speed more. Much closer as real life jet engines work, although ISP variation on speed/altitude is not calculated. If you are seek for even more realism, try AJE (Advanced Jet Engine) mod. EDIT: Ninjaed by Blowfish

I recommend to try SETIctt mod. Link is in my signature. You will still need to build a rocket or two for some basic probe placement, but building successful plane is possible much earlier in tech tree. Also it is quite useful to build ordinary plane/vtol that is going to provide much needed money from contracts or enough science to unlock early tree nodes without too much grinding to loose interest doing it at all.

You will have to try for yourself to find out. I thing that they were not updated for 1.0.2 and nuFAR. Good new is that I can confirm for B9 procedural wings that works properly with dev build of FAR and latest B9 PW patch.

I come across with this thread by accident. It might be good to have link for all threads related to kOS somewhere in OP in main kOS thread forums. Also it is good for you folks who maintain kOS to put some usefull links in signature. When someone does not read OP so often and does not notice changes in OP, he could notice some most relevant stuff in your signature. Especialy when you answer to someones question in any forum related to kOS.

I said it is quick and dirty solution, not a proper one I checked Firespitter again, heli rotors works just fine, hovering function too. But there is issues with collision meshes. nuFAR use those to create voxalizations. Some of parts, like landing gears are not voxelized properly. Heli rotor for example, have voxalization only for one pair of blades, when you increase number of rotor blades, those are not recognized properly by FAR. Also heli rotor, when you crashland heli on port or starboard side and engine is still runing, rotor blades go trough ground without collision at all. Probably KAX use only some part of FS mod and wing code for blades are not properly included trough unity functions. With overhelming changes to aero system, for both stock aero and FAR, lately it is probably not easy to maintain changes for all parts trough proper code. If you need to use cheats (reaction wheels) to make something to work at all considering gameengine limits and time needed to make it work properly, then why not ? Regular user will probably never know difference if pitching works trough wing code or trough other hacks as long it is works for gameplay purpose. I understand your concerns, I'm also all for realism as much as possible, but if you are short in free time to maintain this mod at all, you will need from time to time to make some shortcuts. Anyway, thanks for maintain this mod. Despite some flaws due to lot of changes need to be made to catch up with latest release, I will probably have this mod in second instance of KSP and have some fun with it from time to time. I will try to make notes for all other parts that may need additional checks to be compatible with latest FAR. Right now I can't help you in any other way than trough testing and reporting. Don't mind some criticism from time to time, it is usually because I like something and I want to point out possible ways to improve it

From the OP: Ferram is right, no metter how much info someone provide, there will always be people who are not bothered to read at all. Seriously, don't start this x64 topic again.

My current thinking is this: I'm hesitant to give any more high altitude (low density) thrust than the stock engines, because it encourages air-hogging. I might have considered even suppressing the B9 curves at high altitude relative to stock, but the new aero heating system probably makes that unreasonable. The SABRE should follow the RAPIER's mach curve at low mach numbers (I might give a bit of a bonus at the sound barrier). Thrust growth will continue to about mach 5-5.5 or so and then fall off sharply. In exchange for better thrust growth, Isp, and slightly better static thrust, the SABRE will be more expensive and heavier than the RAPIER. Subsonic engines will gradually loose thrust with mach before hitting zero just above Mach 1. They will have very good Isp. The B9 turbojet will have its mach curve slightly below that of the stock turbojet before falling off between Mach 3 and 4. Isp will be better than the stock turbojet, with somewhat less static thrust. The F119 will gain thrust slightly slower than the B9 turbojet and then fall off between Mach 2.5 and 3. Max static thrust will match the IRL F119 (160 kN) and Isp will be between the stock basic jet and B9 turbojet. I think you are on right track with this. I will try to help with your decision with folowing thought: To be able to go at fast speed and avoid overheating, you need to fly at high altitudes. Speeds above 4 mach is only safe above 20km. To be able to go higher (near level flight 10-15 pitch angle max. and with maximum AoA of 15 degree) you need to go faster. For 30km leveled flight you will probably need speed of 5 mach or more Higher speed also means higher drag, you need more thrust from engines to overcome high drag, and higher you fly, less air you have. More speed you gain, less thrust from engine you have. With FAR and stock RAPIER it is hard to achieve high altitude of 30 km @5 mach due to mentioned limitations. In very rare ocasions, even with highly streamlined plane you will get 24km @ 4.4 mach with RAPIER. To get higher you need more speed, if you dive to gain that speed, your plane will be melted down due to overheating. And you can't go higher because you need to go faster, and you can't go faster because engine thrust drops down rapidly above 4.4 mach and gained speed start to drop with altitude you may gain if you pitch up more. I'm talking this, because of observations trough test flights, I think you should aim for SABRE engines to be able to have at least 30 kN of thrust at 5 to 5.5 mach near 30 km. Also consider air requiremets, so one sabre air intake with cooler should be able to provide enough air for airbrething mode at 30km@5 mach. I hope that it will help for your final decision, and thanks for all your hard work on this.

And I have recalled of old link describing Six Stages of Debugging That is something to cheer you up. All software developers pass trough those stages sooner or later. While we all wait to reach step No.5. it will be good just to put it in "Known issues" part and provide "lame" workaround: save and reload game before making re-entry, because kraken may came nearby and push your craft hard into surface. Not realy a fix, but, when users are aware that such thing can happen there will be less complains about it each day, until it is properly fixed, usualy while working on something completely irrelevant to this bug.

Not a big deal anyway. I have installed Universal storage only because I was thinking that is necessary for MK1 service bay. That one is only required as MK1 cargo bay is not covered with any other mod or stock parts. I didn't realize at first that this item is actually in SETIctt mod. I was tried that DMagic/Universal combo since I spend a lot of time troubleshooting issues I encountered. Those parts does no provide any additional gameplay expirience over other parts that comes with Orbital science and SCANsat mod. They looks cool, but it is not essential for career. I would probably just remove Universal storage properly and make some RAM space for other mods, like Station science that provide that heavy animal food that I used before as test cargo for my crafts. Will see. I still searching for good mod combo that will provide good gameplay expirience and work stable with each other. Anyway, it is good to know what users need to pay attention to, if they use this Orbital science/Universal storage combo. If there is no way to avoid/fix this bug than just put it in some "Known issues" list or something. Cheers, hopefully, KSP 1.0.3 will come out within couple of days, so there will be less bugs to worry about.

It is possible to work retroactively too. If something like that is going to be introduced in one of future version of CKAN, it will be easy to provide legacy support. When CKAN with that new feature is introduced, proposed table that will keep tracking mod relationship will be empty. CKAN have his own database with all dependencies, also it also have all data what is already installed in GameData folder. It is possible to fill necessary data going trough all already installed mods, just filling table data, without actual re-install of each mod. What kind of mod depends on another is already known trough CKAN database repository. Here is requested registry.json. There is several situations I attempted like yesterday. I managed to reproduce situation where DeadlyReEntry is uninstalled and MFI too, but FAR that depends on MFI have remained in gamedata folder. I tried to produce same bug with other mods too, bu it seems that they work properly as intended. Also Tried on separate KSP instance, for test purposes only, it seems that there is no problem there either. I will try to keep eye on stuff like that, so if it happens again, I will save needed json files and let you know about it.

CKAN v1.6.17 KSP 1.0.2 Windows Although, I didn't make a clean CKAN install, I upgraded it trough previously installed version. Also, I was having FAR and modular flight integrator manualy installed. New version of CKAN allowed to uninstall it. I installed again and tried mentioned scenario. I is quite late right now to provide you with json files, I will send you tomorow as soon as possible, for both, before I uninstall Flight modular integrator and after.

I just tried example we discussed earlier. I have installed FAR. It requires Modular Flight Integrator, so it is installed as well. After that I have installed Deadly Reentry that also require Modular Flight Integrator. 1) Tried to uninstall Modular Flight Integrator, while leaving FAR and Deadly Reentry - CKAN alows it. Installed again only Modular Flight Integrator for second scenario. 2) Uninstalled FAR and Deadly Reentry. Neither have asked to uninstall Modular Flight Integrator. After deinstalling both, Modular Flight Integrator is still left in GameData folder. Fortunately, Modular Flight Integrator does not cause too much extra memory usage, but some other mods that have parts/textures can take considerable amount of RAM. Another example is Antenna range that requires Toadacious tools, when you uninstall Antenna range, Toadacious tools are still left. Another example is USI/MKS/OKS mod that recommand bunch of other mods to be installed as well. If you want to uninstall one, otheres are left untouched and user might not remember to uninstall each one of additional dependencies. KAS/KIS is also good example. Someone install KAS, KIS is one of dependencies and deceide to uninstall KAS due to bugs/issues encountered for example and want to remove it until bugs are ironed out. You have uninstalled KAS, but KIS is still left. There is plenty of other examples as well, those are just ones I recall from top of my head. Usually it is not much of issue until user is encountered some bug. When that happens, user is usually advised to uninstall something, most of time some mod that he recall what was last thing installed, but might be also something else. He does this trough CKAN, thinking that he have uninstalled mod properly while there could also be leftovers either from main mod or from some of dependencies. He try to troublshoot issue within game and it happens again, thinking that installed mod is not of issue, while it still cause it because he didn't properly uninstalled it. - - - Updated - - - Yes, something like that, but it will need to do extra checking, so it does not uninstall modul manager, for example that is required for all other mods to work properly.

Well, if you are uninstalled mod, and have no other mod that require it, why you should need to keep personal config file at all when you are no longer want to use it ? Upgrading mod over uninstaling compleatly should be recognizable by CKAN, what you have choose to do, uninstall or upgrade. In case of upgrades CKAN can recognize trough metadata what kind of thing is possible to delete/overwrite and what not. There is two possibilities with personal config files. In one case user have proper config files that contains bunch of customization, like keybindings, window positioning etc. You want to keep that file after upgrade, so you don't have to bother with personal customization again after upgrade, understandable. However, there could be another situation where user have screwed up config file and mod no longer work properly. He is advised to re-install, but even after that, mod does not work properly because faulty personal config file is still in mod folder. It is nightmare for moders to figure out what went wrong and give proper advice to user, without knowlage that he didn't actualy uninstaled mod properly. Later one happened recently when someone opened FAR debug menu and deleted/changed some essential stuff in there and complained that FAR is faulty, no worthy etc. while it is enierly user fault. He has tried re-install trough CKAN without checking out to delete main mod folder between installs. How to satisfy, both, users and modders ? To have easy handling of various mods for user without making modders mad because they have to handle false bug reports more than actual problems. Right now, when you install mod X, it depends on mod Y. Another mod depends on mod Y too. When you want to uninstall mod Y alone, currently(just checked) CKAN alows you to uninstall it, breaking others mod in that way. Also if you want to uninstall mod X, CKAN will uninstall it without leaving other requirements installed. That is Ok if some other mod need it, but when there is no other mod depending on it, user should be able to choose to uninstall it as well. Mostly users will not going to pay attention if something is no longer required or not, leaving potental memory usage in game while you actualy wanted to remove it, making some space in RAM, for example. Didn't come across with such installs, so I didn't know that such thing already exist in CKAN. Sorry for bothering you with that, disregad it. I have some plans to use github in future, but until I sort out things waht I need to have and what not on my end, I only can propose ideas and issues here. Hopefully I will sort things out on my end soon. Thanks for taking time to answer.

If Wanderfounds answer is not enough, I will try to make another galery of screenshots that covers question how to smoothen out the yellow pitch moment line. However, I would not be able to do it before weekend, but I will notify everyone here when I make this one. It seems it is hard to explain it properly without pictures.

Now I have found small bug/glitch that involves SETIctt and contracts. I accepted contract for measuring temperature and pressure on surface. When I finally managed that DMagic unversal storage sci parts working, I have removed stock termometar from craft and I put DMagics one on craft: Univ.storage-presmat/2 Hot. I landed on proper spot from contract, measured required, but contract is not updated. It can recognize job done only if you have used stock parts for measurments. So, it should be either, text change fin contracts to state proper part needed for job, or alow other parts to trigger event that job is done. Other than that, I having fun using Heli to grind money and science by taking measurments on hard to land otherwise spots on planets.

Thanks for looking into this problem in more convinient way. On top of tracking metadata logs, what should be alowed to delete and what not, you could keep track data what kind of mods is using particular submod to keep main mod runing properly. I mean, metadata is OK for current version of mod, but in next version of some mod, files that should be alowed to delete/overwrite could change it's behaviour. But if you have another table in repository that keeps track of data for other related mod needed for main mod to work properly, it will be possible to know if it is safe to delete non empty folder from some mod or not. For example, you install FAR and deadly re-entry mod. Both mods require modular flight integrator to work. For some reason you uninstall FAR. Modular flight integrator need to stay because it is still needed for deadly re-entry. So, on uninstall procedure, CKAN need to check that new table and see if there is still active mods installed in game to see if it is safe to uninstall it or not. If there is still there listed mod that require modular flight integrator, CKAN should warn that is not safe to uninstall it. When you uninstall both, FAR and deadly re-entry, CKAN can know that modular flight integrator is no longer required and ask user to uninstall this one as well. This feature could be helpfull also when user try to uninstall modular flight integrator only, without knowlage that this one is essential for FAR and deadly re-entry. CKAN can warn user about it and disallow uninstall if needed. That new "table" does not have to be too complicated. Whenever CKAN install something it should write name of mod in XML file used for tracking this. Whenever some other mod is installed that depends on this mod, it can add it's name under subnode of XML node where required mod created his "root" install node. So whenever, install/uninstall occur, CKAN can check this and if there is no other mod that require some mod to work, than it is safe to delete entire folder regardless what kind of data is in it. I also wrote couple of pages back some other stuff, that you might missed. Idea how to help with more complicated mod install. Currently, CKAN GUI when you install some mod looks consists of this (more/less) Main zip package for your mod List of mandatory packages (or other mod) that were needed for your main mod to work properly - All of them necessary List of optional (recommanded) packages, things that could improve your mod, but it is not mandatrory for main mod to work properly What i have proposed, to got additional layer of GUI when you install things: Main zip package for your mod List of mandatory packages (or other mod) that were needed for your main mod to work properly - All of them necessary List of mutualy exclusive packages - at least one of them is mandatory for your mod, but if you choose one, other packages on that list must be excluded(unchecked) from install List of optional packages, things that could improve your mod, but it is not mandatrory for your main mod to work properly No.3. could be additional usefull feature. Sorry, don't yet have plans to make github account and open issue/request there. Just wrote some ideas as they pop up, before I forget about them. If it can help, use it, if not, diregard it.

Yes, it is radical, but I agree to that. If something is not CKAN compatible, user should install it by himself, outside of CKAN. But, again, option to be able to wipe out whole folder when you ininstall mod, could also help. I understand concerns that something that user have add in that folder could be lost, but in most cases, there is no such super high important data in mods folder anyway. Mostly it will be just additional config files or in some cases backup of texture files, if you have used DDS converter for mods that still use png or something else. In my case, wiping out whole mod folder could prevent that strange bug I have suffered. There is not lot of users that could investigate true reasons behind it and will just spamm forum in various threads complaining that something is not working. In conclusion, not deleting entire folder from some mod thinking something of ultra high of importance data is in that folder is actualy backfired to CKAN users creating more bugs where they should not exist. Well, my intention is to be more informative about whole "uninstall" discussion and pro/cons behind it. If other users who have read this will pay attention more in future when using CKAN, half of job is already done.

My thoughts behind it was that craft was having some loose joints while still in space, FAR voxelized it and remember it like hollow hull due to loose joints between parts. Due to this and FPS slowdowns caused by other mods, mostly animations that forces FAR voxelization, maybe it wil lbe good idea that FAR disable voxelization while craft is in space, and force voxelization once again, as soon as craft enter atmosphere. Don't know if it is realy a case, just throwing ideas what could be possible reasons behind it. Another question, though, how FAR recognize landing gears as landing gears ? Asking beacause Adjustable landing gears could not be toggled like stock ones can, trough FAR SPH/VAB user interface. Is it possible to add missing info trough MM config, or something else is needed to tell FAR what API function to call when landing gears need to be toggled. Probably landing gears from other mods could suffer from this anoying bug if does not tell properly to FAR what is needed to do.

I proposed earlier that should be debug option in flight to show voxelization points in the same way as it is shown in SPH/VAB editor. With hope that it will alow us to better detect this kind of bug. With those things that are so hard to reproduce you are never sure if you actualy fixed them or not with some code change. Every developer hate this kind of thing, but such is life of developer. Hopefully there is a lot of people in this comunity that are willing to help, so it is just metter of time when someone will be able to provide proper reproduction steps for this bug.

You should enlist any mod you have used to build that craft. quizTechMk1EagleCockpit is missing, don't have a clue what mod is required for that one. With some screenshoot of FAR Static analyzis, AoA sweep between -25 and +25 AoA, at various speeds: 0.2 , 0.35, 0.6 , 0.8 , 1.0 , 1.4 , 2 , 4 mach you could get answer faster.

If you want examples how to build craft with FAR mod, better check official FAR craft exchange thread, link is in OP and in my signature. There is a lot of things that could influence why your craft does not behave as you expect, there is not simple answer to your question because FAR is not simple mod. You need to understand it first, know how to use properly tools provided (graphs) and then you will start to enjoy it. Now, make some screenshots of your aircraft in SPH editor with graph files. Each of them. Then someone could help you with it. But post it in FAR exchange thread, not here, to help out ferram easier tracking of possible issues of mod. For CKAN users, here is example what kind of things could go wrong with CKAN. Also example how to help yourself to iron out possible conflicts between various mods. It is "normal" that some mods are in conflict with each other, but it is not up to developer of any mod to find out which one can't be used with other. It is up to user to find out conflict with few mods as possible to find out reason for some bug. In that way you could expect sooner that developers could find out possible reasons behind it and solve it. Even if they were not able to fix it, you can warn others to be aware what mod does not work well with other. But put some effort from your side into it, don't expect that everything could be solved just like that, soon as you noticed something and reported it.

I was another victim of faulty re-installs trough CKAN. I have described everything in SETIctt thread where I was reported bug for first time. Don't get me wrong, I will continue to use CKAN, but I think that people should be more aware how CKAN works. If you unintsall something trough CKAN and CKAN reports that folder is not empty, it should be done trough more noticable way. I mean, CKAN reports it in that text box, but lot of users will just ignore warning and continue to play game until they encounter some nasty bug and have to chase down trough each mod to find out reason for issue. It could be a better if there is option to force deleting mod folder, even if something is detected inside that was not there in first place. Usualy it is some kind of config file that is created only when you start game with that mod installed. That option should be turned off, by default, but for those who knows what they doing could be available to turn it on. Or, when it is detected that folder is not empty, to ask user if he want to delete it anyway, with big warning text on screen.

Camera bug I finally found out reasons behind it. I will put all data from my previous posts in this one, to make things easier to read if anyone encounter simmilar issues. : It happens when craft contain some part from DMagic orbital science or SCANsat. I'm not exactly sure which one caused this. Everything behave normal and suddenly camera goes out of focus from craft and remain focused on some imaginary object far behind craft. I need more time to narrow down mods involved in this bug. Here is galery of described bug: After some more testing I have narrowed down issues to this part list(from other post): To trigger bug you need to have such part on craft and fly in realtime for about 2-3 minutes until bug occur. I belive all of them are from DMagic orbital science: Presmat / 2 Hot Accelerometer / Gravmax ASERT Atmospheric sensor Goresat Magnetometer Boom Multi-spectar Imaging Platform Mystery Goo Containment Orbital telescope RPWS Antenna SC-9001 Science Soil Moisture sensor Solar particle collector All of them performs weird in SPH editor too. They require free node to be able to attach on craft. When you attach them to craft, some of parts does not allow you to select them again with mouse left or right click either. Some parts highlight themself and parrent part where they were attached, showing parrent part name in tooltip instead of part you hover mouse over. Final tests and reasons behind it. All of those parts are DMagic Orbital science addition to universal storage parts. Forgot to mention this in second post. All of them have "Univer. storage" prefix to their names. Now, what I did. I installed only few mods in second instance of KSP game that serves just for this - discovering reasons of issues. I have made mod installs above clean vanilla game instalation. Once I have opened SPH, I could not found those problematic parts. I have checked main game to see what I have of mods installed and add missing ones to test KSP game folder. Before I forgot to mention, besides DMagic Orbital science, I have manualy instaled FAR and Modular flight integrator. Rest of mods are installed trough CKAN. I have added one by one, SCANsat, SETIctt, KIS, KAX and their dependencies. I could not reproduce that bug, and I could not find those problematic parts in SPH either. Finally, I have found necessary mod for those parts to appear: Universal storage. I have installed this and problematic parts have apeared in SPH, although with different mesh/icons. I was confused slightly, but tested them anyway. There was no problem with them in SPH editor. I have made several flight tests too, no problem at all with them. OK, there must be something else in my main game folder that was causing issues. First, those parts can't work without universal storage mod. I checked CKAN. Universal storage mode is not shown as installed in my main game. Something fishy is going on here. How those could apear in SPH if Universal storage mod is not installed and it is required to be, for those parts to be available in SPH editor ? Finally, figured out what was happen. Previously, I was installed Universal storage mod trough CKAN. Played game for a while, checked out memory usage and eventualy I have uninstalled it trough CKAN because all needed from that mod is that small 1.25m service bay. Rest of cargo bays are more/less covered trough stock parts or other mods. To be clear, it is not that I didn't like universal storage, but due to all kind of memory issues I have remove it to make some RAM space for other nice mods around. Later on I have installed DMagic Orbital science mod. I was thinking that all was fine. Now, chasing down reasons for issues encountered, I double checked my main game gamedata folder. There was Universal storage folder inside. Not a full mod, but some XML config file was there. That thing was confused Orbital science mod, thinking that Universal storage mod was installed, parts are displayed in SPH while those should not be, because Universal storage mod is not complete in folder. When I was deleted that folder, problematic parts were no longer available in SPH. Installed again Universal storage mod, those behave normaly in SPH, checked them in flight, no longer issue with camera after 2-3 minutes of flight. Don't ask, I have no clue why that incomplete install cause issues only with camera, I was expecting some kind of CTD earlier, not that wierd camera behaviour. Anyway, lesson learned, whenever you remove some mod trough CKAN, double check that whole folder from that mod is deleted too, otherwise you will be chasing ghost bug for days. Sorry for long post, but I was thinking that is necessary to explain everything in one place and help out people with similar issues how to help themselfs.

Thanks Crzyrndm for all time and effort you have put into this patch to make it work.