kcs123

Is it possible to be able to engage lock while still in SPH/VAB ? I was created patches for stock parts like this: @PART[strutCube*] { %MODULE[InnerLock] { isPermaLock = true isSwitchable = false } } @PART[structuralMiniNode*] { %MODULE[InnerLock] { isPermaLock = true isSwitchable = false } } It seems that this one makes such part collideable with everything. It makes cliping into other parts dangerous (kraken invitation). Is it possible to create MM patch that new part only collide with same part type that have such option enabled, not with all other parts ? That would be much safer to use when you want to hide such parts by cliping into other parts for aestetic reasons.

It is not related with "FOR SETIRebalance", there is some other command that multiply science point with factor of 0.7 That should give you 70% of stock science points from experiments. However it no longer can be "0.7", it can only be whole number "1", "2", or similar. It might be necessary to divide it by "2" or some other close number instead of multiplication. I just catched message on screen about it, since I was enabled showing log messages on screen, but haven't yet pinpointed exact command line that need to be changed in SETI config files.

I was able to set it just once in SPH, but those settings does not seems to have effect in flight for some reason. Try to hang provided craft on launch clamps. I was lucky and able to set rotatron to stay at zero degree. However, pivotron is set to 65 degree, and due to unbalanced mass it swings slightly left and right as shown on picture: I was expected from joint spring and damper to slow down oscilation (swinging), at least that I was observed with old IR plugin and manually set values in config file. I don't need strong spring forces here, just enough to push wheels slightly in neutral position after unexpected jump over bumps. Otherwise spring need to be weak enough to allow rotation when craft encounter high slope. Anyhow, tested some more with alpha version of InnerLock mode from @whale_2, looks promissing: With collision enabled between certain parts on places where I want them and some light rotation shock absorbers, this kind of rover will be reasonable simple to create (partwise) and simple to use, yet quite robust and forgiving for careless drivers. What I would like to see from InnerLock mod is slightly more forgiving misalignment when comes to locking between parts. Those new parts from @ZodiusInfuser looks great, but are not practical enough for craft on picture. In some other application might perform just fine. Might also be smaller in size too, but that can be adjusted later on with tweakscale configs. Anyhow, this is just one example of possible usage. Once everything is ironed out, other users will come out with even better crafts.

Due to MM changes, SETI fails to apply 0.7 science multiplication. It produce not an integer number for multiplication or something like that in log file.

Finally I was able to do some testing. Here is link for craft files and output log. I doubt that output log is of any help, but it is included regardless. Just a prototype for future rover. It might be easier to debug things if you have something to test against. Only Kerbal Foundries are required for wheels Full gallery from crash test site. spring and damper on uncontroled parts have no effect, or I have set them too low after saving/loading craft in SPH it is no longer possible to set values for spring adn damper joint values powered hinges have too weak joint, IR motor is not strong enough This is what I mean when I say that powered hinge is too weak: Joints just splited when I tried to drive around and test it. This one suppose to be foldable variant of same kind of wheels. It is possible that I missed something in attempt to set limits of rotations. And what "test test" button do ?

Yes, most probably it comes from KSP stock game and unity game engine itself. Not that I'm expert on this, but I come across to post that is talked about it recently and for some odd reason I tend to remeber such stuff: As much as I'm able to understand this, main issue is lack of decimal digits in float point type used for enough precision. This issue is reason why you have "Reattach fixed meshes" button in last IR plugin available. At least you can fix it to some degree if not completely avoid. And you can avoid such thing to happen if you don't time warp while having craft with such IR parts on flight scene. If you need to time warp, try to switch to tracking station, warp time and then get back to flight scene. Other possible workaround of this issue would be careful placing of IR parts and usage new locking parts as soon as new mod from whale_2 become available. You can see possible fix as described in this post: First alpha of InnerLock is available to try on github. While not everything is possible to solve with just one mod, it might be possible with combination of few different mods. Hope that tiny bit of info will help.

It can be safely "assumed" that torque on motors is "magicaly adjusted" with additional gears/mechanics in combination to motors on each IR part, so you can have some constant torque that would not allow for motors to suffer. Simply put, same motor can be used for small part and for large part to move it, but it will need to move larger part with higher mass for longer period of time and at slower speed due to gearbox reduction. I use this to calculate gravity and weight of craft trogh kOS script: local Body_g to SHIP:BODY:MU / (SHIP:BODY:RADIUS+altitude)^2. local CraftWeight to SHIP:MASS * Body_g. SHIP:BODY:MU is gravitational parameter of SOI body for your craft. Those values should be obtainable trough KSP APIs somehow, because kOS mod reads them from game database. In most cases you can even disregard current ship altitude due to low influence on gravity acceleration when you are close to planet. I think that would be sufficient to use only IR part mass for that calculation, reading each part mass that is attached to IR part might be overkill and cause unwanted FPS dropdown, when used just for game purpose.

How about: EC/s = part_mass * speed * some_constant Would be much closer to real life energy usage that depends on mass and speed at same time. "some_constant" is probably needed to fine adjust EC usage in game as "EC" is made up unit that does not have much relation with real life. IRL energy consuption would be related to all part mass that IR part want to push, not just itself, but that would be overkill to code just for that. That way, when you scale up part mass, you will "properly" scaled up EC usage. If you slow down IR speed, you can adjust to have same EC consuption, but with cost of moving IR part more slowly.

Following post deserves to be linked in this thread too, for all players that use AirplanePlus, SKT and KAX parts along with SETI:

I'm not sure for easy way to recognize AP parts, maybe trough company name or something ? But, you can take a peek into Unmanned Before Manned file "UnmannedBeforeManned-TechTree.cfg" for example. @PART[KAXradialprop]:NEEDS[KAX,!SETIctt,!SETItechtree,!ETT,!OpenTree,!RP-0]:AFTER[KAX] { @TechRequired = earlyAviation } This piece of code move KAXradialprop part to earlyAviation tech node. In similar manner you can do for AP parts, but you need to enumerate each part by name. Don't know if it is possible to move it by mod name, or some other variable that is available only for AP mod.

I think that it use either, firespitter, B9PartSwitch or similar plugin that allow switching textures/meshes. However, either one you want to use have to be supported trough IR plugin. I'm not sure if it can be handled only trough part config file / MM patch file. It might be useful not only for wheels and engines, but for other similar part as well. Downside is that it is one more mod dependency for everything to work properly. Have yet to inspect B9PartSwitch for myself to be able to tell how exactly to use it. EDIT: It seems that only MM part config data is required to use it. At least from documentation, have yet to diggest how to apply that on IR parts.

CKAN data is most probably outdated. Most recent official working version with "all in one" archive can be found in this post: There will be no point to update CKAN data as new version of IR plugin is close to release. It would just bring more confusion. It may also happen that KSP 1.4. comes out too that will bring additional workload to all modders as well as CKAN dev team.

Have you tried those wheels with FAR installed ? For some reason it seems that FAR fix some of symmetry issues. I have created rover with KSP 1.2.x when FAR was not being updated for long time and IR was also not being actively maintained. The result was that I was placing IR parts and wheels without symetry, not only due to symmetry issues but also to avoid autostrut issues too. Link to workaround gallery for autostrut issue. However, loading that rover in KSP 1.3.1. game with FAR resulted in wheels turning in oposite direction. This is reason why I think that FAR somehow fix symmetry, but I don't know how. Having different parts for wheels would not be much of trouble for me, but it would be nice to have attachment node on those wheels, to have ability for more precise attachment if those are not placed in symmetry. Otherwise it can produce uneven forces and lead to have craft that always turn left or right despite how much you want to go in straight line.

KJR licence is GNU General Public License v3.0 that allows modification and redustribution as long as you keep same licence. It might be OK to distribute modified version for testing purposese, but inthe long run it will make a confusion in community, what KJR version is required and what not. It might be better if you create pull request for code change. And just as I was looking at KJR github code, I seee that you already did that. We all have to be patient until ferram got free time to merge this in main release. Until changes are made from ferram side, you might distribute your forked/changed version of KJR with disclaimer that should only be used temporary for testing purposes. For full release of IR next, it will be better for community to be patient about it.

I also use MJ mostly for info readouts, dV-stats, orbit info and similar. Also for creating maneuver node for inerplanetary transfer becasue I'm not yet ready to deal with that kind of math. For the actual craft control, I more like to use kOS. Not that is superior to anything else that is available out there, but because it allows me to learn more about all of necessary math behind rocket science at pace that I'm confortable with, to maintain fun part of playing KSP.

I think that both, tweakscale and KJR are made in a way that original author of mod that KJR and tweakscale interact with, does not have to bother to change anything in their mod to make it work. Not all of modders are willing to bother to change their code, (in some cases it might be too complicated) to make it work with some other mod that is made later on. Therefore, KJR and tweakscale offers support for other mods trough config files. I'm not sure if developers of KJR and tweakscale are more confortable with one aproach of solving issue than other one. What they would think that fit better on the long run. As for new joint strength, it is hard to predict what kind of value would suit of all possible craft application. All that can be fine tuned later on. It might be good to expose those values in config file, to allow users to experiment with it and report back what kind of value suit better for their craft. I'm not sure if those values from part config file do that or something else is involved: I was hoping that I would have more time on this weekend to help with testing, but hopes and wishes are one thing, but real life always kicks in with something else to deal with.

Similar thing happens to me with kOS script autopilot on complex craft with heavy moded game. Or if my craft experience aerodynamic failure or some other similar malfunction. Sometimes it is necessary to put "wait" command for 0.5 to 1 sec. before attempting to stage again. That will allow KSP game engine to "recalculate" craft and properly assign new properties to craft after staging. It may be similar issue with TCA too. Ability to have "wait" timer between staging might help with this.

Tweakscaling of IR parts are dealed trough "IR_TweakScale.cfg" file. It also depends on module names "MuMechToggle", "IR_Stack" and "IR_Free", how it will be scaled. Becasue IR Next use different module names it probably created similar issue with tweakscale configs as it is with KJR mod. Too "springy" craft with long parts are alway being issue on scene loading, this is one of reason why KJR is created in the first place. It is not only restricted to IR parts. As much as I was able to understand trough config files, IR joints strength are already made as strong as possible to overcome such issues. That is one of reason why you would more likely to see that joints of other parts start to drift sooner than joint of IR parts that create force when you start to move IR parts of craft. @AccidentalDisassembly, you might want to try other mod that help with KSP stock game issues on loading flight scene:

CKAN only offer download of legacy parts from old archive, because few last of IR plugin releases only include core plugin without parts. Zodiusinfuser parts were in BETA stage for a long time and not being ready for release, therefore not covered by CKAN. However, things are moving recently due to activities of several developers. Until recently, few of us have maintained a step by step guide how to install everything manually from several downloaded sources. Zodiusinfuser have created all in one archive with most up to date files and few new parts that were never published yet. You can find that archive here: There is more news. New "IR next plugin" code is under development and testing that could solve some issues with IR parts that were being around for some time, plus some new features that was not possible before: Besides that, whale_2 develop new independent mod that allow collision of two parts of same craft plus ability to lock position of desired pieces of craft (those new parts from Zodiusinfuser on post above). Locking certain parts of craft make a great workaround for driftting bug issue with IR parts under time warp or when you switch/reload flight scene. For example if you leave IR Candarm in "working" position and leave scene or use time warp, there is chance that IR parts would visualy drift appart. On the other hand, if you "park" IR parts and lock them with ability of new mod and new parts, such "drift" would not happen. When all of those new exciting is finished it would be more sense to put them on CKAN. Until then, be patient and install all stuff manually.

You can found various additions for various text editors on kOS github page. For windows OS, I recommend notepad++ and language addition for it from linked page. Users with other OS such as linux or MAC might have differente preference what text editor offer better features.

ferram was accepting PRs in the past, I don't see a reason why he would not accept this one too.

Nice to know that you found proper solution for issue and notified others about it.

It is "normal" to expect that not everything is going to work flawless on the first run. It is huge improvement, considering that it yesterday it was not possible to use it at all. Some testing and observations have to made first, to find in what circumstances things become broken. Once that is reliably detected, it can be solved either, by "good user behaviour" (once you know why bad things happens it may be possible to avoid it) or maybe with some additional "if" conditions in code, to prevent user to make a mistake. Anyhow, don't give up on this yet. With some more colaboration between players, other developers and some more coffee even greater things may happen. This community is much more cooperative than quite a lot of other communities gathered on other forums on other games/projects. Issue with KJR is easy to solve, each user can add aditional info into KJR xml file for himself. Once IR next is released, PR can be sent to ferrram to include it in next version of KSP. Or you can use same module names as old IR plugin, but that would prevent to have both mods installed side by side. For testing purposes, I recommend anyone to make additional instance of KSP and not mix old IR plugin and this one.

Thanks for clarification, I have yet to unlock SAR scanner, that explains things. M700 no longer provide any science, so I'm probably squeezed out everything from it, it should be time to turn it off and save some CPU time.

New models are better options for sure. Not necessary to have visible springs and animations for shock absorbers, some kind of piston like VR_Dev showed should suffice. "Spring" can always be hidden visualy inside part and apply force by "magic" physics. Until new parts are made, for test purposes is good enough to copy some existing part to get visual representation in game and add new properties trough config file. @Rudolf Meier, thanks a lot for not giving up on this, who knows, after few more coffees even better solutions might pop up Anyhow, I will try to test this ASAP and report back.