kcs123

I have stock resource scanning disabled and I'm pretty sure that I have covered entire planet with M700 scanner(I can see resorces discovefred over poles and previous/next orbit equally distributed on map). Quite a lot days passed since those were put in orbit. Multispectral scanner (biome map) and low resolution altitude scan is done too (entire map visible). Only thing might be missing is hi-res altimetry scan (if multispectral scan does not cover that). Is that a reason for only having 80% ? I still have to unlock few more tech nodes with additional scientific parts. It is either that M700 didn't completed scanning or I still need additional scan with some different part. If I don't need additional scanner then something went wrong in my savegame. Is it possible to check how much M700 have covered ?

I think i tis fine to use both of them at same time. Haven't tried it since B9 variant was released long time ago, though.

Hmm, I did some testing when you said that parts drift and you are right. But from my observation in game it is not too bad. What i did is that I created craft with free rotate rotatron, but with some force on jointSpring and dampers. Part is rotated 2-3 degree due to uneven weight of parts attached on left and right side of rotatron. I saved and reloaded game. After reloading, parts on crafts seems to be in exact position as I saved, except that rotatron shows 2X more degree of rotation than it is saved. It's not issue for free rotating parts as those don't have any limits, so that kind of thing is hard to notice in game that some bug is present. Anyhow, I was able to fix that trough existing button on right click menu that @Ziw created some time ago "Reattach Fixed Mesh". It didn't produce any wild behaviour on craft (parts moving/jumping due to spring forces or something similar). After that, rotatron in question showed again proper 2-3 degree offset as it was when I saved game for first time. So, while not ultimate solution, some workaround might be possible. Again, it might be good to have additional variable in part config file to do following only on certain parts that is safe to do: after loading check for parts that have variable "ForceReattachingFixedMesh" to true exacute piece of code from button "Reattach Fixed Mesh" only on those parts to set proper nullpoint position let the game engine physics do the rest of stuff Another possible solution might be observed after @whale_2 publish his WIP mod, to enable collision on certain craft parts. In video he already showed that part drifting issue is solved with his mod by locking certain parts. Hope that my rantling is of some help, not much more I'm able to do right now.

I noticed something else that might be bug or might be harmless. Under SCANsat background settings I got info in brackets for Kerbin, Mun and Minimus that is scaned 80%. But, all maps are covered to all edges, pretty much sure it is 100% or at least 99%. I'm not sure for M700 stock resource scanner, but it show up resources over poles, resonable amount of time have passed to cover all planet surface too, so while it is nbot possible to tell is it 100% scaned, it is for certain more than 80%. Do I need to scan with narrow band scanner to get 100% or I'm missing something ? I have started scan 2-3 versions of SCANsat earlier, before new optimization code if that matter.

You need to Rename IR control group in different way at Candarm #1 and Candarm #2. Having specific name convention on parts in each group can help too but it is not necessary. IIRC, it is possible to edit groups and IR parts in flight too, but haven't did that kind of thing for long time, so can't tell for sure.

Just additional note/reminder, as there is still minor issues with IR GUIs and clicktroughs. In case that some of those old issues still exist, new mod from linuxgamer may help with it:

We can be happy to get this one working at all, considering that original developers are on hiatus due to real life commitments. At time of active development it was enough to use additional config file for tweakscale mod. As for all other wishes, you might get better chance to post it in new WIP IR plugin thread, it might have better chance to be solved: As for clicktrough issues, it will require changes in IR plugin too, but this mod can help to solve that one too:

Some slopes are still slippery for bot, but it walk much, much better than before Great progress.

Zodiusinfuser already covered it, why I asked for request to expose those values to VAB, in flight scene on rigtht click menu. So far we know it can work on rotational free moving parts. It should be allowed for free moving parts to exceed limits -360 to +360 due to game engine limits, as much as unity game engine "see" that. However, we might set limit values in part config file in different way. Let say, we set limit of movement from 0 to 300 degree and from 0 to -300 degree for inverse movement. Inside allowed limits of movement, values for spring and damper are linear like it is set in config file or trough right click menu. As soon as limit is exceeded, joint spring forces become exponentially stronger. Hopefully, strong enough to produce feeling like it is colided on something. I wrote some thoughts how it might be possible to do it in following posts from one that I linked earlier: For now, in first beta version of mod it would be enough to have additional variables in part config file: jointSpringDampingExposed - true/false - to allow user to change value in VAB and maybe in flight scene too nullPoint - 0 degree in above example or angle where jointSpring/Damping are equal, or resting point rotateMinForce and rotateMaxForce - not true limit, but point where jointSpring force start to rise exponentially It might not be possible to prevent strange behaviour in all situations, where part rotaqte above desired limits, but it can help a lot if used properly. Currently with only adjusting spring and damping values it is possible to set how far some part can move, on picture below, tubes are placed horizontally in SPH and since one tube is larger and heavier it fall down and rotate free moving rotatron. However, it does not get to 90 degree of rotation due to spring joint forces: While currently is not possible to have true limits of movement, it might become after releasing of additional WIP mod: With that one it might be even possible to create linear shock absorbers, but for now it will be of huge help if you can just expose required things to right click menu. That will allow more experiments and future development while not breaking anything that we know that works for sure. Proper mesh parts and gamebalancing can be done later down the road of development.

You might be interested in similar WIP mod: @VR_Dev might use some help, your work looks very similar.

Something is wrong then.I got also latest USI installed with CKAN. I got similar craft that consist of 3 crew Mk stock command module and stock habitate module for tourist journey to Mun and back. Although, I didn't ditched habitat module, only turned off/on habitat as needed to save EC. All seats filled with kerbals. While I have habitat running, I got around 97 days or so for homesick/habitation. (writting from top of my head so it might not be exact number). As soon as I turn off habitation, timer drops to 7 days. It is almost enough for Minimus too, depending of planed trajectory. It does not bother me even if it expire, as I got on craft command probe and kOS CPU to run custom scripts, as I become lazy to execute maneuver nodes by hand. Of course, I was set up a comm network in Kerbin SOI already, grinding money at some time from those sattelite contracts. From my perspectiver, habitation/homesick work as intended.

There was some leftovers on UI that were not disabled clicktrough and key pass trough usage of IR UI. Make some screenshots and provide log file, it will be easier for devs to fix it when they grab some free time for it.

Depends on craft you work with. Sometimes is just enough to use KJR mod along with IR that strength out all of joints in game. In other cases, you may not want to use hinges at all. Use extendatrons instead. Like in this album or my iteration of same idea. It is always stronger to use something that forms triangle than just one simple hinge or rotatron.

You should not translate everything literally. Instead of direct translation, try to think of meaning, or rather represenation of "conics" in game. In this scenario, it may also be written as "multiple node handling" or "additional node controls". instead of "Change conic samples" it can also be "Number of maneuvers to execute" or something. Because it handles other nodes that will be executed after first one and allow you to switch in time, which one you want to tweak. Hope it will help you to translate it.

I recently got similar NullReferenceException error in otherwise prooven working script that I used a lot of time. It is set to be executed at boot time. Rather simple script, to execute maneuver node burning. Case when it failed is on complex craft with lot of parts and possible other installed mods too. I solved issue by adding wait 1. command, to allow game physics to settle down before starting any calculation when some of ship parts/properties not being completely unpacked on scene change. Or something similar that caused issue. Just something to keep on mind when starting up scripts on boot/scene change.

Yep, I understand that there will be always some kind of game/engine limits. Having those on motorized parts might still be impossible/hard to achieve. However, I already experiment with free rotating parts where is no big issue. Except that I need to change values in config files to adjust it for craft that I currently build. Not very convinient for full public release of mod. Maybe some kind of tweakable module in part config file ? To be able to choose on what part it can be enabled and on what part not. Free rotating parts would be safe to have such option, with default values of zero, for both values, like it is now in part config file, but optional to have in game menu slider to experimet with. After some beta testing, limits for those can be suggested. Pretty much this. I already have two possible scenarios. In one where collisions is not wanted, for example in creating aircraft with variable sweep wings, where you clip extendatrons or rotatrons/hinges within wing and hull parts. In other scenario, you may want to restrict movement of othewise free moving parts, without using motors of some kind. Being able to deceide in game should some part is allowed to collide or not and should it collide with only specific other part of craft will be nice to have.

Small request, if possible, while you already rewriting large piece of IR code, is i tpossible to expose jointSpring and jointDamping values to right click menu of IR part ? Reasons for that is in discussion in IR Model rework thread, jsut as reminder if you missed it: You might also benefit from other WIP mod from @whale_2, as described in this thread: Can't help you much more than posting links to other mods that share similar ideas.

You should make them at time when you will enjoy making them. That will be the best reward you will ever get.

Reminds me how much computer games have elvolved since Elite was published for the first time in 80's.

Hmm, last time I was check it is partless mod. But it require to you to unlock certain tehnological tree node to get all of features TCA can offer. IIRC, only stock probe is required on craft.

Yep, usage of procedural parts and tweakscale makes difficult to balance for any tech tree available out there. Similar is with tweakscale too. Only true balance is to restrict yourself in a way how you use those parts. For example, I tend to use tweakscale only for IR parts. But since I use also B9PW, I don't use much of any other wing parts. Exception is rockets, when it is more simple to use just pre-made stock parts for fins. But, this is what moding is all about, to adjust whole game for personal preference.

I'm not sure if it is bug or intended. When you enable advanced view trough option menu, you got two buttons: -Orb - clicking on this with either left or right mouse button will always move maneuver node to -1 orbit period -+Orb - clicking with left mouse button moves node to +1 orbit period, but clicking on same button with right mouse button moves node for -1 orbit period Don't know why there is two buttons for almost same thing. Probably it was confusing for new users of mod to have both functions on just one button and there was some space left on GUI for that additional -1 Orb button.

^^This. Yep, it is very subjective to determine a point when you need to switch to higher version. As more time pass, better mods become with latest KSP version and less and less mods provide support for older KSP. At some point, you jsut need to bite a bullet and live with it. As a general rule of thumb, don't switch to latest KSP version in heavy moded install immediately when it becomes available, you can expect a lot of things to become broken and it will be hard to isolate is it just one mode or interaction between mods that cause issue. On the other hand, don't wait for too long to switch on latest KSP verion, there will be high chance to be on your own when comes to support.

It will be hard to help you with that. You will need also older version of IR, but can't tell from top of my head exact order of installs to make it work. Grabber and sampler were broken in one version of IR in the past and repaired later on, but I can't recall details.